Home / Knowledge hub / Iframe sandbox
Knowledge hub
Iframe sandbox
An attribute that strips embedded content of most of its powers.
What it means
The sandbox attribute on an HTML iframe applies a set of restrictions to the page inside it. With an empty value it blocks scripts, forms, pop-ups, plugins and navigation of the parent page, and it treats the content as coming from a unique origin, so it cannot read the host's cookies or storage.
You then loosen it by naming only the permissions the embedded content needs, such as allow-scripts or allow-forms. Everything you do not list stays off, which is the opposite of the default for an ordinary iframe.
Why it matters
Embedded content is code you do not fully control: a widget, a payment form, a document preview, a customer's HTML. Left unrestricted, a flaw or a hostile page inside the frame can run scripts, open windows or push the visitor somewhere else.
A sandbox limits the blast radius. It is a cheap, built-in layer when you must show user-supplied content, and it pairs well with a content security policy as part of defence in depth.
How it shows up
You meet it wherever an application shows content from another source: rendered email, marketing widgets, preview panes, and user-written pages on a separate domain. The attribute is easy to add and easy to weaken by accident.
The classic mistake is combining allow-scripts with allow-same-origin on content from your own origin. The embedded page can then remove its own sandbox attribute and run freely. Others are adding every permission to make a widget work, or sandboxing a frame but serving the content from the main site. Check the tokens, not just the attribute.
Questions people ask
Iframe sandbox, answered
What does an empty sandbox attribute do?
It applies every restriction. Scripts do not run, forms cannot submit, pop-ups and plugins are blocked, and the content is treated as a separate origin.
You add permissions back one at a time with tokens.
Why are allow-scripts and allow-same-origin dangerous together?
If the framed page is on your own origin, scripts can reach the parent and remove the sandbox attribute. That undoes the protection.
MDN warns against using the two together for content from the same origin as the page.
Is a sandboxed iframe the same as a separate domain?
No, but they work well together. A sandbox removes powers from the content, while a separate domain keeps it away from your cookies and storage under the same-origin policy.
For user-supplied HTML, use both.
Does it stop clickjacking?
No. It controls what the framed page can do, not who may frame your pages. To stop others framing yours, use CSP frame-ancestors or X-Frame-Options.
See clickjacking for how that attack works.
Is there a header version?
Yes. The Content-Security-Policy sandbox directive applies the same kind of restrictions to the document that receives it, which is useful for serving untrusted files such as uploads.
It is a good fit for downloaded user content.
Sources
Where this comes from
Related
Terms that sit next to this one
Clickjacking
Tricking someone into clicking your button while it is hidden from them.
Content Security Policy
A header telling the browser which scripts a page may load.
Same-origin policy
The browser rule that stops one site's scripts reading another site's data.
X-Frame-Options
A header that stops other sites from placing your page inside a frame.
HTML injection
Getting your page to render markup an outsider supplied, even without running scripts.
What can the embedded page do?
Embedded and user-supplied content is where small gaps turn into real findings. We find vulnerabilities in web apps and APIs and prove each by exploiting it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.