Sandboxing iframes

iframe sandbox flags explained: lock down embeds, re-enable only needed capabilities, combine with CSP.

advanced3 min readUpdated Aug 4, 2026

security
iframe
sandbox
csp
embeds

Third-party embeds (payments, media, ads, docs) should not inherit full power over your page or their own default capabilities. The sandbox attribute applies a strict set of restrictions to an iframe, which you then re-enable surgically.

Docs: MDN iframe sandbox, HTML spec sandbox.

Default sandbox = highly restricted

<iframe src="https://embed.example/widget" sandbox></iframe>

Empty sandbox blocks scripts, forms, popups, same-origin access, etc. The frame is a unique opaque origin unless you opt into tokens carefully.

Common tokens

Token	Allows
`allow-scripts`	JavaScript
`allow-same-origin`	Treat as real origin (dangerous with scripts)
`allow-forms`	Form submit
`allow-popups`	window.open
`allow-popups-to-escape-sandbox`	Opened windows not sandboxed
`allow-downloads`	Downloads
`allow-modals`	alert/confirm
`allow-top-navigation`	Navigate top (rarely needed)
`allow-top-navigation-by-user-activation`	Safer top nav variant
`allow-presentation`	Presentation API

<iframe
  src="https://docs.example/preview"
  sandbox="allow-scripts allow-popups allow-forms"
  loading="lazy"
  referrerpolicy="no-referrer"
></iframe>

Dangerous combo

<!-- Almost undoes sandbox for same-origin content -->
sandbox="allow-scripts allow-same-origin"

Together, the frame can remove sandboxing via script if it’s same-origin to a capable document. Avoid for untrusted content.

Combine with other headers

<iframe
  src="https://pay.example/checkout"
  sandbox="allow-scripts allow-forms allow-popups"
  allow="payment *"
></iframe>

Permissions-Policy / allow — features like camera/payment.
CSP frame-src — who you may embed.
COOP/COEP — isolation interactions when relevant.
postMessage — still validate origins — postMessage.

User content previews

Prefer rendering untrusted HTML in a sandboxed iframe on a separate origin (null origin or cookie-less domain) rather than dangerouslySetInnerHTML on your app origin.

Interview out-loud

“sandbox locks down iframe capabilities; I re-enable only scripts/forms/popups the embed needs. allow-scripts + allow-same-origin is a red flag. Pair with CSP frame-src, allow attributes, and strict postMessage checks.”

Reviewer prompts

What is the asset (session, PII, money movement)?
What is the attacker capability (web, XSS, network, dependency)?
Which control fails closed if misconfigured?
Is the server still enforcing authz?
Any new third party, iframe, or URL sink?

Residual risk note

Browser controls reduce likelihood and impact; they do not eliminate bugs. Prefer defense in depth: safe defaults in code, strict headers, and monitoring (CSP reports, auth anomaly alerts). When product pressure weakens a control, write down the accepted risk and a revisit date.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.