XSS in React: dangerouslySetInnerHTML and Third-Party Scripts

React automatically escapes all values rendered via JSX before inserting them into the DOM. When you write {userInput} in JSX, React calls the equivalent of textContent assignment — the value is treated as text, never as HTML. This prevents the majority of XSS attacks in React applications by default.

dangerouslySetInnerHTML={{ __html: htmlString }} is React's escape hatch that bypasses the automatic escaping. The name is intentionally alarming: it tells you that you are taking responsibility for the safety of the HTML string. React sets innerHTML directly, executing any HTML including scripts and event handlers.

You genuinely need dangerouslySetInnerHTML when rendering HTML that comes from a rich text editor (like TipTap or Quill), a CMS that stores HTML, or a Markdown-to-HTML converter. These sources produce real HTML markup that must be rendered as HTML, not as escaped text.

If the HTML string contains <script>stealCookies()</script> or <img src=x onerror="stealData()">, setting it as innerHTML executes the attacker's code. Any user-supplied content passed directly to dangerouslySetInnerHTML without sanitization is a critical XSS vulnerability.

DOMPurify is the industry-standard HTML sanitizer for browsers. It parses the HTML string in a sandboxed context, removes dangerous elements and attributes (script tags, on-event handlers, javascript: URLs), and returns a safe HTML string. Usage: DOMPurify.sanitize(dirtyHtml) before passing to dangerouslySetInnerHTML.

Third-party scripts (analytics, chat widgets, ad networks) run with the same permissions as your application JavaScript. A compromised or malicious third-party script can read document.cookie, access localStorage, read form inputs, and make requests to external servers — all without any indication to the user.

Content Security Policy is an HTTP header that declares which scripts are allowed to execute. Even if XSS payload is injected into the DOM, a properly configured CSP can block its execution by restricting inline scripts and allowing only whitelisted script sources. CSP is the second line of defense after input sanitization.

npm packages are a real XSS attack vector. A dependency can include malicious code that exfiltrates environment variables or user data. The 2022 node-ipc incident and the 2021 ua-parser-js compromise demonstrated that widely used packages can be taken over and poisoned. Audit dependencies with npm audit and use lockfiles.

A successful XSS attack enables an attacker to steal the user's sessionStorage JWT token (sending it to an attacker-controlled server), perform actions as the authenticated user (API calls using the user's session), modify the DOM to display phishing content, or log every keystroke the user makes in the application.

The Trusted Types browser API requires all DOM sinks (innerHTML, eval, script.src) to receive special typed objects rather than raw strings. This prevents string-based XSS payloads from reaching the DOM at the platform level. React is working toward Trusted Types compatibility, and CSP can enforce it.

The safe pattern for rendering CMS HTML: fetch the HTML, pass it through DOMPurify.sanitize() with an allowlist of safe tags and attributes, then render with dangerouslySetInnerHTML={{ __html: cleanHtml }}. Never skip the sanitization step, even if you trust the CMS, because the CMS database itself could be compromised.

What does DOMPurify do when you call DOMPurify.sanitize(htmlString)?

React automatically escapes JSX values, preventing most XSS. dangerouslySetInnerHTML bypasses this for legitimate HTML rendering — always sanitize the input with DOMPurify first. Third-party scripts and compromised npm packages are supply chain XSS vectors. Content Security Policy provides a second defense layer. Successful XSS enables token theft, impersonation, and phishing.