Safety
CSP sandbox vs iframe sandbox for Public Pages
March 3, 2023
CSP sandbox vs iframe sandbox for public pages is two places the same idea can live. The sandbox attribute on your <iframe> limits what that child document may do. The CSP sandbox directive applies sandbox flags to the document that sent the header — as if the page itself were framed with those flags. Neither stops someone else from framing you; that is frame-ancestors (and X-Frame-Options). A brochure that only embeds a map or a video usually wants iframe sandbox, not a site-wide CSP sandbox that can break its own scripts. RoastMyOpsec grades framing headers on the landing HTML. It does not parse iframe sandbox flags, does not score CSP sandbox as a standalone F, and does not exploit clickjacking.
The practical difference
iframe sandbox is a parent restricting a child you chose to include. CSP sandbox is you restricting your own document. allow-scripts plus allow-same-origin together weaken either form — treat that pair as almost unsandboxed. frame-src decides which hosts may be framed; it is not sandbox.
A CSP sandbox with no tokens is a locked-down document. That is rarely what a marketing CMS wants on the home page.
How to choose a control
You embed untrusted HTML: iframe sandbox without allow-same-origin unless you have a documented exception. Your page must not be framed: frame-ancestors, not CSP sandbox. You serve a static untrusted preview origin: CSP sandbox on that origin can make sense. Your main brochure: skip CSP sandbox; keep scripts working and sandbox the third-party iframes.
| Control | Who it restricts | Typical miss | Takeaway |
|---|---|---|---|
| iframe sandbox | A child you include | allow-scripts + allow-same-origin | See iframe sandbox vs frame-ancestors |
| CSP sandbox | This document | Shipping it on a CMS home page | Rarely for brochures |
| frame-ancestors | Who may embed you | Missing both CSP and XFO | Clickjacking control |
| frame-src | Which hosts you may frame | frame-src * | See frame-src vs object-src |
When CSP sandbox still wins
CSP sandbox wins on a dedicated origin that only renders untrusted HTML (previews, user content). iframe sandbox still wins for widgets on a normal marketing page. Missing CSP sandbox on a brochure is healthy. Pair with postMessage vs CORS if the embed also talks to the parent.
What the roast can prove
Framing headers on the landing response can surface. Missing CSP sandbox is not a finding. iframe sandbox flags are not parsed. Confirm both yourself. Pair with CSP vs X-Frame-Options if clickjacking is the actual risk.
Common mistakes
The first mistake is CSP sandbox on the home page because a generator listed every directive.
The second mistake is treating CSP sandbox as frame-ancestors.
The third mistake is allow-scripts and allow-same-origin together and calling the page sandboxed.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Does CSP sandbox stop clickjacking?
- No. Use frame-ancestors (and X-Frame-Options) to control who may embed you.
- Should brochure sites set CSP sandbox?
- Usually no. Sandbox the iframes you include. Missing the CSP directive is not a roast F.
- Does RoastMyOpsec score CSP sandbox?
- No. It grades framing headers and does not parse iframe sandbox flags. No clickjacking payloads.