Start with an empty sandbox attribute, which applies every restriction, then add only the tokens the widget fails without. Most widgets need allow-scripts. Avoid combining allow-scripts with allow-same-origin on content from your own origin, because that pairing lets the framed page remove its own sandbox.
How the attribute works
MDN describes the sandbox attribute on an iframe as controlling the restrictions applied to embedded content. An empty value applies all restrictions. Space-separated tokens lift particular restrictions one at a time.
That makes it an allowlist: you grant what is needed. For a store, that is a useful default, because widgets such as reviews, chat, store locators or loyalty panels rarely need the full power of your page.
Tokens a widget might ask for
| Token | What it allows | Typical need |
|---|---|---|
| allow-scripts | Run JavaScript inside the frame | Almost every widget |
| allow-forms | Submit forms | Sign-up or review forms |
| allow-popups | Open new windows or tabs | Links that open elsewhere |
| allow-popups-to-escape-sandbox | Opened windows are not sandboxed | Links to a partner site that must work normally |
| allow-same-origin | Treat the frame as its real origin | Widgets that need their own cookies or storage |
| allow-top-navigation | Let the frame navigate your whole page | Rarely, and ask why |
| allow-modals | Show alert and confirm dialogs | Rarely |
MDN also notes a detail that surprises people: if a sandboxed frame opens a new page and the popup token is set without the escape token, the new page inherits the same restrictions, and a form submission there can silently fail.
The one combination to avoid
MDN states that when the embedded document has the same origin as the embedding page, using both allow-scripts and allow-same-origin is strongly discouraged. The framed page can then remove the sandbox attribute, making it no more secure than having no sandbox at all.
For a widget served from the vendor's own domain, the situation differs, since the frame is cross-origin to your page. Even so, grant allow-same-origin only when the widget breaks without it, and record why.
Steps to choose tokens
- Embed the widget with an empty sandbox attribute.
- Load the page and watch the browser console for blocked actions.
- Add one token at a time, reloading after each, until the widget works.
- Write down each token and the reason in your tag register.
- Recheck when the vendor ships a major change, since needs can grow.
What a sandbox does not do
A sandbox limits the framed page. It does not make the vendor trustworthy, and it does not help if the vendor's script is a plain script tag on your page rather than inside a frame. The OWASP cheat sheet suggests combining iframe sandboxing with a Content Security Policy for high risk applications, and notes the frame and the main page can talk through postMessage.
Payment widgets often have their own rules about how they must be embedded. Follow your payment provider's instructions and PCI guidance first, and use the sandbox for the other widgets.
Where Safeguard fits
If a widget arrives as an npm package rather than a frame, Safeguard's dependency scanning and policies apply to the package. Frames themselves are a page-level control. A free scan is at gold.safeguard.sh/scan.
Quick check
Does an empty sandbox attribute mean no sandbox?
No. An empty value applies all restrictions, which is the strictest setting.
Can a sandboxed widget read my checkout form?
Not through the page's DOM, since a frame is a separate document. Do not put the widget on the checkout page without a clear need.
Sources
Last reviewed: 19 October 2026.
