DangerouslySetInnerHTML

dangerouslySetInnerHTML is React’s explicit escape hatch for inserting raw HTML into the DOM. It bypasses normal text escaping, so the browser parses the content as markup instead of plain text. It is useful for trusted rich content, but it must only be used after robust sanitization and careful review of the data source.

Expanded Definition

dangerouslySetInnerHTML is a React-specific mechanism for rendering raw HTML when application code needs to preserve markup that would otherwise be escaped. It is not a validation feature, and it does not make content safe; it simply tells React to hand the browser a string of HTML for parsing.

That distinction matters because the risk is not the API itself but the trust boundary around the data source. When the string comes from a CMS, chat transcript, ticketing system, or user-generated content, the application must treat it as untrusted until it has been sanitised and reviewed. Security teams often pair this pattern with server-side filtering, allowlists for permitted tags and attributes, and a strict content policy. Guidance across the industry is still evolving on how much sanitisation belongs in the client versus the backend, but no single standard removes the obligation to control the input source. The MDN innerHTML reference is useful here because it shows the browser primitive React is deliberately exposing in a controlled way.

The most common misapplication is treating trusted formatting as trusted content, which occurs when teams store rich text from external users and inject it without sanitisation or provenance checks.

Examples and Use Cases

Implementing dangerouslySetInnerHTML rigorously often introduces content-handling overhead, requiring organisations to balance rich presentation against the cost of sanitisation, review, and testing.

• Rendering sanitised CMS content for help centres or product pages, where editorial teams need headings, links, and emphasis preserved without allowing scripts.
• Displaying approved email templates or marketing fragments imported from a controlled source, after filtering unsafe tags and attributes.
• Converting markdown or rich text into HTML on the server, then passing only the sanitised output to the React component.
• Showing third-party content such as support ticket notes or forum posts, where the application first applies a strict allowlist and then re-checks the output before render.
• Handling security advisories or compliance notices that contain structured formatting, while ensuring the source pipeline is locked down and auditable.

For teams aligning application behaviour to browser security guidance, the OWASP XSS guidance remains a practical reference for understanding how unsafe HTML insertion becomes a cross-site scripting issue. React documentation also reflects the same design principle: the escape hatch exists for rare, explicit cases rather than routine rendering.

Why It Matters for Security Teams

Security teams care about dangerouslySetInnerHTML because it creates a direct path from untrusted content to executable browser context. If sanitisation fails, a single compromised record can become a client-side attack surface affecting session integrity, data exposure, and user trust. That makes the term relevant not only to developers but also to AppSec, product security, and governance teams reviewing content flows, supply-chain dependencies, and review gates.

The control question is not whether raw HTML should ever be rendered, but whether the organisation can prove the source is trusted, the content has been normalised, and the allowed markup is limited to what the application truly needs. In practice, this often intersects with secure coding baselines, content-security policies, and release review for customer-facing systems. The NIST Cybersecurity Framework 2.0 is relevant because it frames the governance and protective controls that should surround application input handling.

Organisations typically encounter the business impact only after a stored or reflected XSS event exposes users to malicious script injection, at which point dangerouslySetInnerHTML becomes operationally unavoidable to address.