-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add trusted types to react on server side #16555
Conversation
ReactDOM: size: 🔺+2.1%, gzip: 🔺+2.1% Details of bundled changes.Comparing: 507f0fb...df6577b react-dom
Generated by 🚫 dangerJS |
We've just published a |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution. |
Apologies for closing. We've accidentally pushed a master branch to the repo (due to an old fork), then deleted it, and this lead to a bunch of PRs getting auto-closed. GitHub seems confused and unfortunately does not offer a way to reopen this against |
Trusted Types
Trusted Types (spec, introductory article) is a new experimental DOM API implemented within the WICG , with a working Chrome implementation.
The API creates a few new objects available on the global object in the browser, like most other web APIs (impl in TS and in Closure compiler).
Under certain conditions, controlled by a HTTP header (analogous to Content-Security-Policy behavior), the API can enable the enforcement - then it changes the signature of several DOM API functions and property setters, such that they accept specific object types, and reject strings. Colloquially, DOM API becomes strongly typed.
For example, with Trusted Types Element.innerHTML property setter accepts a TrustedHTML object.
Trusted Type objects stringify to their inner value. This API shape is a deliberate choice that enables existing web applications and libraries to gradually migrate from strings to Trusted Types without breaking functionality. In our example, it makes it possible to write the following:
The above code works regardless if the Trusted Types enforcement is enabled or not.
Reading from the DOM is unaffected, so Element.innerHTML getter returns a string. That's for practical reasons -- web applications read from DOM more often than they write to it, and only writing exposes the application to DOM XSS risks. Typing only the setters allows us to secure web applications with minimal code changes.
Adding Trusted Types to React for server side
Unfortunately, there are no Trusted Types (TT) on server side. However, it’s really easy to introduce a reflected xss attack via server side rendering. Markup rendered on server side is rendered to string (without any DOM emulation) and returned as a response from the server and there is no way TT can prevent this attack. This creates inconsistency when rendering on client and server side (client side would fail with TT violation), which shouldn’t happen. Also, if application uses hot reloading, you will get a TT error after each reload (because React templates are re-rendered to DOM, this time on client).
This PR enables applications to use Trusted Types on server side. Functions inside ReactDOMNodeStreamRenderer.js and ReactDOMStringRenderer.js in react-dom/server package now accept optional third parameter with trusted types polyfill implementation. If TT are provided, they are enforced, otherwise no behavioral change is made. If TT are enforced, we check whether the values are trusted before creating the markup from them and throw an error otherwise.
Reference