Iframe Sandbox Policy Builder

Pick the capabilities an embedded frame genuinely needs and get the minimal sandbox attribute, with warnings for the token combinations that quietly undo the sandbox.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

What are you embedding?

Where does the content come from? This changes what allow-same-origin actually means.

The sandbox attribute is deny-by-default

Adding sandbox="" to an <iframe> removes almost everything the framed document can do: no script, no forms, no popups, no downloads, no top-level navigation, no modals - and the document gets a unique opaque origin with no access to cookies, storage or anything same-origin. Each token you add gives one capability back.

That direction matters. Omitting the attribute entirely is not a neutral choice; it is the opposite of sandboxing. The safe starting point is an empty sandbox, adding only what the content demonstrably needs.

The combination that removes the sandbox entirely

allow-scripts and allow-same-origin together, on content served from your own origin, is not a weakened sandbox. It is a removable one.

The framed document runs script with your origin's privileges. Script inside it can reach its own frame element through window.frameElement, delete the sandbox attribute, and reload itself with no restrictions at all. Whatever the sandbox was meant to contain is then running unsandboxed in your origin, with your cookies.

This is why the origin question on this page is not cosmetic. When the content is cross-origin, allow-same-origin restores that site's origin, not yours - which is normal and necessary for a payment provider or a video player. When the content is same-origin, it restores yours, and the sandbox stops being a boundary. The tool grades the same pair of tokens as critical in one case and merely notable in the other, and that difference is the entire point.

If you need to run untrusted content and give it script, serve it from a different origin. Even a subdomain you control is enough, because allow-same-origin then restores the subdomain rather than the origin holding your session.

The other tokens worth thinking about

allow-top-navigation lets the frame navigate the entire tab with no interaction at all. This is the mechanism behind most malvertising complaints: an embed silently replaces the page the visitor was reading. allow-top-navigation-by-user-activation permits the same thing but only after a real click or key press, which removes the silent case. Use that one.
allow-popups-to-escape-sandbox means anything the frame opens is not sandboxed. By default a popup inherits its opener's sandbox, which is the safe behaviour - this token deliberately switches it off. Keep it only for a legitimate external flow such as 3-D Secure.
allow-downloads lets the frame start a download. A file arriving while someone is on your site carries your site's apparent authority regardless of where it came from.

Sandbox is one layer, not the whole answer

The attribute restricts what framed content can do; it does not stop the content being loaded or make it trustworthy. Pair it with a Content Security Policy that limits which origins may be framed at all - see CSP Generator - and with referrerpolicy so the frame does not learn the full URL of the page embedding it.

If you are the one being embedded rather than the one embedding, the relevant control is frame-ancestors: check it with Clickjacking Protection Tester.

Everything here is generated in your browser

Your selections never leave the page. There is nothing to upload - the output is an HTML attribute assembled locally from the capabilities you picked.

Frequently asked questions

Why does the same token pair get a different severity depending on the origin?

Because it does a different thing. allow-same-origin restores the framed document's real origin. For cross-origin content that is the provider's origin, which is ordinary. For your own content it is yours, and script in the frame can then reach out and delete the sandbox attribute - so the restriction can be removed from inside.

Can I sandbox an embed I do not control, like a YouTube player?

Yes, and you should. Most providers need allow-scripts, allow-same-origin and allow-popups, which is what the media preset selects. That still blocks top-level navigation, downloads and forms, which is a meaningful restriction on an embed you cannot audit.

Does sandbox stop the frame loading at all?

No. It restricts what the loaded document may do. To control which origins can be framed in the first place, use CSP's frame-src directive.

Is an empty sandbox="" a mistake?

It is the strongest and often the correct setting - for rendering untrusted HTML, an email preview or user-submitted markup, you usually want exactly nothing to run. It is only a mistake if the content genuinely needs a capability you have not granted.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.