Cybersecurity glossary
What is an Iframe Sandbox?
Learn what the iframe sandbox attribute does, which permissions allow-scripts and allow-same-origin grant, how sandboxing reduces embed risk, and how to configure it safely.
Definition
The iframe sandbox attribute applies a set of extra restrictions to an embedded browsing context—blocking scripts, form submission, top navigation, and same-origin access by default—until specific allow-* tokens re-enable only the capabilities the embed needs.
Why iframe sandbox matters
Embedding content is unavoidable: payment widgets, HTML previews, docs viewers, ads, and partner tools. Every iframe expands the trust boundary. The sandbox attribute gives hosts a declarative way to run embeds with least privilege.
Without sandboxing, a compromised or hostile embed can run script, submit forms, and—depending on origin—interact more freely with your page. With careless allow-* combinations, sandboxing can be undone.
How sandboxing works
An iframe with sandbox (even empty) enables a restrictive set of flags. Tokens re-enable individual capabilities.
Embed with sandbox enabled
Add the sandbox attribute to apply default restrictions to the framed document.
Default locks engage
Scripts, forms, plugins, top navigation, and same-origin treatment are restricted.
Allow only required tokens
Add allow-scripts, allow-forms, or other flags solely when the embed needs them.
Keep origin isolation in mind
Prefer a distinct origin for untrusted HTML so allowlists cannot recreate a powerful same-origin frame.
Monitor and review
Treat new allow-* tokens as privilege grants subject to security review.
Important allow tokens
| Token | Enables | Caution |
|---|---|---|
| allow-scripts | JavaScript execution in the frame | Needed by many widgets; increases attack power |
| allow-same-origin | Normal origin treatment for the frame URL | Dangerous combined with allow-scripts on same-origin content |
| allow-forms | Form submission | Can exfiltrate data via POSTs |
| allow-top-navigation | Navigate the top-level browsing context | Phishing and open-redirect style abuses |
| allow-popups | Window.open / target=_blank style popups | Pair with noopener practices and careful UX |
Recommended patterns
Untrusted HTML preview
Sandbox on a unique origin; avoid allow-same-origin with allow-scripts.
Third-party widget
Start fully sandboxed; add the minimum tokens the vendor documents.
Same-site helper frame
Still sandbox if the frame only needs a subset of capabilities.
Defense in depth
Combine sandbox with CSP frame-src, Permissions Policy, and CSP inside the frame.
Configuration checklist
- Default every untrusted iframe to sandbox before adding allow tokens.
- Never combine allow-scripts and allow-same-origin for attacker-controlled same-origin content.
- Prefer separate origins (e.g., usercontent.example) for HTML isolation.
- Gate top navigation behind user-activation tokens when possible.
- Align iframe allow= Permissions Policy features with least privilege.
- Review vendor embeds when they request new sandbox exceptions.
- Test that restricted actions fail closed in QA.
- Document why each allow-* token exists for each embed.
The practical takeaway
An iframe sandbox loads embedded documents with strong default restrictions and requires explicit opt-in for scripts, forms, navigation, and origin privileges. It is a primary control for hosting untrusted or third-party content.
Grant the fewest tokens possible, watch the allow-scripts + allow-same-origin combination, and isolate sensitive previews on dedicated origins.
Related security terms
Clickjacking
Framing attacks; sandboxing complements framing controls on embeds you host.
Content Security Policy (CSP)
Policy layer that can further constrain framed and framing content.
Permissions Policy
Controls powerful features available to pages and iframes.
Cross-Origin Resource Sharing (CORS)
Cross-origin access model that interacts with embedded content designs.
Frequently asked questions
What does iframe sandbox do?
It loads the framed document with strict default restrictions. You then opt back into specific capabilities with tokens like allow-scripts or allow-forms.
What is the danger of allow-scripts with allow-same-origin?
Together they can let the sandboxed frame remove its sandboxing if it is same-origin with the parent, effectively escaping the restriction model.
Should user-generated HTML previews be sandboxed?
Yes. Sandboxed iframes are a common pattern for isolating untrusted HTML, ideally on a separate origin as well.
Does sandbox replace CSP?
No. Sandbox constrains the embed’s capabilities. CSP constrains resource loading and other policies. Use both for defense in depth.
Can a sandboxed iframe navigate the top page?
Not by default. Tokens such as allow-top-navigation or allow-top-navigation-by-user-activation re-enable controlled top-level navigation.
Is sandbox enough for third-party widgets?
It reduces risk but widgets often need several allow-* flags. Combine with Permissions Policy, CSP frame-src, and least-privilege origins.
How do I test sandbox configuration?
Load the embed and verify blocked actions fail (script execution, form posts, top navigation) unless explicitly allowed.
References
Explore authoritative guidance and frameworks related to iframe sandbox.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.