Prevent XSS When Rendering External Content

Follow the value, not its label

Cross-site scripting (XSS) becomes possible when attacker-controlled content is interpreted as executable code in your application's browser context.

Treat an API response as an untrusted source, even when the API belongs to your organization. A URL value supplied by external content is also an untrusted source. Ownership, a TypeScript annotation, or a successful string-shape check does not establish that a value is safe for every browser context.

To assess a rendering path, trace one value from its source, through props and local variables, to the browser operation that interprets it.

dangerouslySetInnerHTML is a rendering sink: it asks the browser to interpret a string as HTML. A prop and a local variable can make the path look ordinary, but they do not change the source of the value.

HTML interpretation can process more than visible elements. For example, an external element can contain an event attribute such as onerror, creating an executable path. You do not need to insert or trigger a script tag to recognize the risk.

A runtime check can establish that bodyHtml is a string, and ExternalArticle can describe its shape. Neither proves that its contents are safe for HTML interpretation or navigation.

Inspect this complete trace. It is deliberately unsafe and is shown only for analysis; do not use this rendering pattern.

title and summary are plain text fields in this article preview. Even when external text contains characters that resemble markup, render it as an ordinary JSX expression.

React escapes string values placed in JSX. The browser displays the characters instead of interpreting them as HTML elements. This keeps a text-only requirement out of a raw HTML rendering sink.

Replace raw HTML rendering for text-only fields with normal elements and JSX expressions. No sanitizer, manual escaping, or HTML interpretation is needed for this requirement.

Do not pre-escape a value before placing it in ordinary JSX. React already performs text escaping, and manual escaping can produce confusing double-escaped output. Output context still matters: plain text uses JSX; a justified rich HTML region and a link destination need separate handling decisions.

src/ArticleCard.tsx — replace the text-only rendering

The article highlights region has a real formatting requirement: paragraphs, emphasis, and lists must remain visible. That makes it the one justified rich HTML region in this preview.

article.bodyHtml is still an untrusted source. Before it reaches the dedicated raw-HTML rendering sink, reduce it to exactly the formatting the feature needs. Title and summary do not have that requirement; they remain plain text in ordinary JSX.

A sanitizer is context-specific: it prepares this one rich HTML output boundary. It does not decide whether a link destination is acceptable.

In your local React TypeScript project, install the maintained sanitizer package.

Use a maintained sanitizer rather than a home-grown filter. Keep DOMPurify updated through your normal dependency maintenance process.

This highlights feature permits formatting only. The allowlist contains paragraph, emphasis, list, and line-break tags. It intentionally excludes links, images, and embedded content. ALLOWED_ATTR: [] is paired with ALLOW_ARIA_ATTR: false and ALLOW_DATA_ATTR: false so the feature's no-attribute policy also disables DOMPurify's default ARIA and data-* attribute families.

Replace the contents of src/ArticleCard.tsx with this component. cleanHtml is created from external bodyHtml immediately before the only raw-HTML rendering boundary.

The component continues to render title and summary as plain text. The separate url field is not rendered here: navigation gets its own URL policy later.

src/ArticleCard.tsx — replace the file contents

Treat timing as part of the boundary

A sanitization boundary is a timing rule as well as a tool choice. External bodyHtml remains an untrusted source until every operation that produces HTML is complete and DOMPurify processes that final value. Only then may the result cross into the dedicated rendering sink.

If untrusted markup is appended after sanitization, it bypasses the boundary. Keep this rich HTML path narrow: title and summary remain plain text in ordinary JSX; only the justified highlights region reaches the raw-HTML sink.

ExternalArticle says that bodyHtml is a string. A runtime shape check can establish that the field exists and has that shape. Neither establishes that its contents are safe for HTML interpretation.

Escaping is the right behavior when content is plain text. It is not a replacement for sanitization when the product intentionally renders rich HTML. Under the highlights policy, unsupported element wrappers can be removed while their safe text content remains visible.

This pipeline looks close to correct, but its final concatenation reintroduces the original untrusted source after DOMPurify has finished. displayHtml is therefore not a sanitized value.

Inside ArticleCard — unsafe review example

If a final operation genuinely produces HTML for the highlights feature, perform it first. Then sanitize that final value, store the result as cleanHtml, and send only cleanHtml to the rendering sink. In ordinary layouts, prefer JSX rather than creating additional HTML strings.

Inside ArticleCard — rich HTML boundary

article.url is an untrusted source, even when it arrives in a value typed as string. React’s escaping of plain text does not establish a URL policy for an anchor’s href.

Treat navigation as its own rendering boundary: parse the candidate, decide whether the feature supports the parsed destination, then render a link only for an accepted result. A rejected value becomes noninteractive text.

Create src/safeUrl.ts. The helper rejects blank input and parsing failures, then checks the parsed protocol against this feature’s exact allowlist: http: and https:. It returns the parser’s url.href, never the unchecked input.

HTTP is included here to support local development. This is the example feature’s URL policy, not a universal recommendation.

src/safeUrl.ts — create or replace the helper

src/ArticleCard.tsx — add the import, then add the local value before return and the conditional branch inside the existing <article>. Keep the previously established plain-text and rich-HTML rendering unchanged.

The URL constructor resolves relative and protocol-relative forms against window.location.href before the protocol check. These are inspection examples: do not browse to unsupported destinations.

A protocol check answers one question: “Is this a supported kind of web URL?” It does not answer: “Must this destination stay inside this application?”

A public Read more link can allow an external https: origin. An in-app destination feature can require a stricter URL policy: after parsing, its destination must have the current page’s exact origin.

Keep the protocol check for both policies. Enable the additional origin rule only for a feature that truly must remain in the current application.

In src/safeUrl.ts, retain the existing blank-input, parsing, and protocol checks. Add an exact parsed-origin comparison only when sameOriginOnly is enabled.

Both url.origin and window.location.origin contain the scheme, host, and port. Comparing these parsed values avoids errors from raw-string prefixes or hostname substrings. A destination accepted by this URL policy is permitted for this feature; it is not proof that a remote website is trustworthy.

src/safeUrl.ts — replace the helper with this version

Assume the current page is https://app.example:5173/articles.

The URL constructor resolves relative and protocol-relative inputs before the URL policy evaluates them. Therefore, //outside.example/guide becomes an HTTPS destination under this current page, but its parsed origin is still external. These are inspection examples only; do not browse to them.

Use your own local React + TypeScript project. If you completed the earlier steps, keep that project and replace the four files shown in this step. Otherwise, create a small Vite project with the optional setup below.

Every field in sampleArticle is an untrusted source, even though this local fixture is under your control. The same rendering boundaries apply when the values later arrive from an API.

Run these commands only if you need a fresh project. If you already have the project, run npm install dompurify from its root instead.

Create or replace this file. It provides the external article fixture and its TypeScript shape.

Create or replace this helper. It parses a candidate before enforcing the protocol and optional exact-origin URL policy, then fails closed with null.

One component has three distinct output contexts. Render title and summary as plain text. Sanitize the justified highlights rich HTML immediately before its dedicated rendering sink. Pass the URL through the URL policy before creating a link.

The highlights policy allows only formatting tags and no attributes: it explicitly disables the default ARIA and data-* attribute families as well. Unsupported element wrappers can be removed while safe text content inside them can remain visible.

Create or replace the complete component. Links do not belong in the rich HTML region; the separate url field receives its own URL policy.

Replace the default app component with this composition. The second line deliberately applies the stricter same-origin URL policy to the fixture’s external destination.

After saving all four files, start the local development server from the project root and open the Local address shown in your terminal.

Use browser inspection rather than activating suspicious destinations. Change one fixture value at a time, refresh, observe the result, and then restore the baseline value.

1. Set summary to <em>Reader note</em>. The angle brackets remain visible; no em formatting element is created.
2. Set bodyHtml to <p onmouseover="alert(1)">Read the <strong>highlights</strong>.</p>. Bold formatting remains. In the Elements panel, confirm that the event attribute is absent; do not hover to test it.
3. Set url to javascript:alert(1). The card shows Link unavailable.
4. Restore the baseline external URL. The card’s public link is accepted, while the separate same-origin status remains rejected.

These are inspection examples, not destinations to browse.