feat: Add iframeSandbox config #157
Conversation
README.md
Outdated
| @@ -79,6 +80,8 @@ export { Button } from '../Button'; // Re-exporting a named export | |||
| // etc... | |||
| ``` | |||
|
|
|||
| The `iframeSandbox` option can be used to control the `sandbox` attribute on Playroom's iframe. A value of `true` will set `sandbox="allow-scripts"` or a custom string value can be used. | |||
There was a problem hiding this comment.
I wanted to document this feature somewhere, but let me know if this is too distracting to be upfront in the readme and you'd like to move it elsewhere.
| @@ -12,6 +12,18 @@ interface IframeProps extends AllHTMLAttributes<HTMLIFrameElement> { | |||
| intersectionRootRef: MutableRefObject<Element | null>; | |||
| } | |||
|
|
|||
| const playroomConfig = (window.__playroomConfig__ = __PLAYROOM_GLOBAL__CONFIG__); | |||
There was a problem hiding this comment.
I wasn't sure if I should read the config in this component or if the value should be read elsewhere and passed as a prop. I tried to follow existing patterns, which looked like it's ok for components to read config.
Using sandbox breaks Cypress assertions because it restricts iframe access.
parshap
changed the title
|
Hey Mate, Thanks for the PR. Controlling the sandbox attribute seems reasonable. However, I'm not sure about the Probably also worth mentioning that at least |
|
Hey @mattcompiles. I think you're right that a default of |
|
@parshap @mattcompiles it would be great to note these security concerns/recommendations in the readme, especially the advice to put Playroom on to its own domain. From my understanding, hosting Playroom on a github.io subdomain would be secure (as far as it couldn't read any sensitive cookies/localstorage), but I expect people may want to deploy Playroom in other ways and may not be immediately aware of these considerations. |
Hi! We’re looking at integrating Playroom on our design system style guide at NerdWallet. Given Playroom’s inherent ability to execute arbitrary code, one of our security engineers had some recommendations:
sandboxattribute in Playroom’s iframe to sandbox arbitrary code executionThis PR is about the second item and implements the
sandboxattribute in the<Iframe>component driven byplayroom.config.jsconfig. Credit for the implementation also goes to @mhensley-nw.This security concern was also raised in #125.
Unbreaking Webpack HMR
Like #125 mentions, using
sandbox=”allow-scripts”breaks Webpack hot module replacement in development. This is because Webpack expects anOriginheader andsandboxmakes requests omitOrigin. This is fixed by using webpack-dev-server’sdisableHostCheckoption, which makes Webpack not expect theOriginheader. More information in this Webpack issue: webpack/webpack-dev-server#1604.Configuration
This is an opt-in feature using the
iframeSandboxkey inplayroom.config.js. A value oftruedefaults to”allow-scripts”or a custom string can be used. We think”allow-scripts”might be a sane default, so you may consider making that the default in the future.