Q189: React Security Boundaries, dangerouslySetInnerHTML and Trusted UI

What Interviewers Want To Evaluate

This question checks whether you understand React security boundaries. Interviewers want XSS, escaping, dangerouslySetInnerHTML, sanitization, trusted content, markdown rendering, URL safety, auth boundaries, permission checks, CSP, and supply chain risk.

Senior answers should be clear that React helps, but does not make unsafe content safe.

Short Interview Answer

React escapes text content by default, which helps prevent many XSS bugs. But if you use dangerouslySetInnerHTML, render untrusted markdown, build unsafe URLs, or trust client-only permission checks, you can still create security vulnerabilities. Untrusted HTML must be sanitized with a trusted sanitizer, URL schemes must be validated, authorization must be enforced on the server, and CSP can provide defense in depth.

Detailed Interview Answer

React escapes normal text interpolation.

<p>{userInput}</p>

If userInput contains HTML, React renders it as text.

This is a strong default.

But security bugs still happen when applications bypass that default.

dangerouslySetInnerHTML

This API inserts raw HTML.

<div dangerouslySetInnerHTML={{ __html: html }} />

The name is intentionally loud.

It is dangerous when html comes from users, CMS content, markdown, imports, or external APIs without sanitization.

Sanitization

Sanitization removes dangerous HTML, attributes, and protocols.

It should handle:

script tags
event handler attributes
javascript URLs
dangerous SVG
iframe policies
style injection
unknown tags
malformed markup

Do not write a sanitizer with regex.

Use a maintained sanitizer and configure it intentionally.

Markdown and MDX

Markdown can produce HTML.

MDX can execute components.

A handbook or docs platform should treat content trust carefully.

Questions:

who can author content
can content include raw HTML
can content import components
are embeds allowed
is content reviewed
is sanitization needed
does build-time content execute code

Trusted local MDX is different from user-submitted markdown.

URL Safety

Unsafe URLs can create XSS or phishing paths.

Validate:

href protocol
redirect targets
image sources
iframe sources
download links
mailto and tel formats

Block or sanitize javascript: and unexpected protocols.

For redirects, allowlist internal paths or trusted domains.

Client UI Is Not Authorization

Hiding a button is useful UX.

It is not security.

Server-side authorization must protect:

data fetching
mutations
API routes
Server Actions
file downloads
admin operations
tenant boundaries

The client can improve discoverability, but the server must enforce access.

CSP

Content Security Policy provides defense in depth.

Useful controls:

script-src
style-src
img-src
frame-src
connect-src
object-src none
base-uri
frame-ancestors
report-uri or report-to

CSP does not replace sanitization, but it can reduce exploit impact.

Third-Party Components

React apps often use third-party packages.

Review:

maintenance status
known vulnerabilities
bundle behavior
DOM insertion
HTML parsing
dependency tree
license
update cadence

Packages that render HTML or handle rich text deserve extra scrutiny.

Common Mistakes

A common mistake is assuming React prevents all XSS.

Another mistake is rendering CMS HTML directly.

Another mistake is trusting markdown without understanding raw HTML rules.

Another mistake is validating permissions only in the UI.

Another mistake is allowing arbitrary redirect URLs.

Senior Trade-Offs

Security is layered.

Use React escaping, sanitization, URL validation, server authorization, CSP, dependency review, and logging together.

The right level of restriction depends on content trust and product needs.

Debugging Workflow

When reviewing a risky UI:

identify all untrusted inputs
find raw HTML insertion
review markdown or rich text pipeline
validate URL protocols
check server authorization
inspect CSP
review third-party packages
test malicious payloads
add regression tests
document trust boundaries

Interview Framing

Start with React's default escaping. Then explain where it is bypassed, how to sanitize, how to validate URLs, why server authorization matters, and how CSP fits.

Revision Notes

React is a helpful default, not a complete security model.

Key Takeaways

Never treat untrusted content as safe just because it appears inside a React component.

Follow-Up Questions

1. How does React escape text?
2. Why is dangerouslySetInnerHTML risky?
3. Why not sanitize HTML with regex?
4. How can markdown become unsafe?
5. What URL protocols are risky?
6. Why is hidden UI not authorization?
7. Where should permission checks happen?
8. How does CSP help?
9. What third-party packages need scrutiny?
10. How would you review a rich text feature?

How I Would Answer This In A Real Interview

I would say React escapes text by default, but raw HTML, markdown, unsafe URLs, and client-only permission checks can still create vulnerabilities. I would sanitize untrusted HTML, validate URLs, enforce authorization on the server, use CSP as defense in depth, and document content trust boundaries.