Prefer an iframe over a script tag, add the sandbox attribute with the fewest permissions that work, set a referrer policy, lazy load below the fold, and consider click-to-load so nothing contacts the provider until the visitor asks. Each step shrinks what an embed can see or do.
Iframe or script?
A script tag runs with your page's full privileges. An iframe puts the third-party content in its own browsing context. MDN describes the iframe element as embedding another document into the current one, and the sandbox attribute as controlling restrictions applied to the embedded content. For a video or map, an iframe is usually the safer shape.
Attributes that matter
<iframe
src="https://widgets.example.net/player/123"
title="Product walkthrough video"
sandbox="allow-scripts allow-presentation"
referrerpolicy="strict-origin-when-cross-origin"
loading="lazy"
allow="fullscreen"
></iframe>
| Attribute | What it does | Guidance |
|---|---|---|
| sandbox | Applies restrictions, and each token lifts one | Start empty, add tokens one at a time |
| referrerpolicy | Controls what URL information the provider receives | Choose deliberately |
| loading | Lazy defers the request until the frame nears the viewport | Use for frames below the fold |
| allow | Grants permissions such as fullscreen to the frame | Grant just what the widget needs |
| title | Describes the frame for assistive technology | Always set |
One warning from MDN is worth repeating: if the embedded document has the same origin as the page, using both allow-scripts and allow-same-origin lets the embedded document remove its own sandbox, making it no more secure than no sandbox. Many third-party widgets need scripts, and if they live on another origin, that combination is less risky, but never add allow-same-origin out of habit.
Lazy loading and privacy
MDN notes that lazy loading defers the request until the browser expects the frame to be needed. That saves bandwidth, and it also means fewer providers are contacted on pages where the visitor never scrolls to the embed. MDN also points out that lazy loading can let a server infer approximate scroll position, so it is not a privacy tool by itself.
Click-to-load facade
For the strongest control, show a static preview image and a play button. Once the visitor clicks, you insert the iframe. Before that click, the provider sees nothing. This approach also speeds up the page.
Referrer policy
The default in modern browsers is strict-origin-when-cross-origin, as MDN documents. That sends the origin but not the full path to other sites over HTTPS. If your URLs contain anything sensitive, set a stricter policy explicitly. See which referrer policy value stops URL leaks.
Add a content security policy
A policy that restricts frame sources to named providers prevents a compromised template from adding new embeds quietly. For static hosts that cannot set headers, see CSP in a meta tag for static sites for what a meta tag can and cannot do.
Keep a list
Record each embed, its owner, why it exists and when it was last reviewed. Remove widgets nobody uses. See CDN supply chain security risks.
Where Safeguard fits
Safeguard lists dependencies and watches for new advisories, which covers the packages you bundle yourself. Embeds loaded from a provider need the controls above. Free scan: gold.safeguard.sh/scan.
Quick check
Does sandbox stop a widget from tracking visitors?
Not by itself. It limits what the frame can do on your page. The provider can still see requests the frame makes.
Can I skip sandbox if I trust the provider?
You can, but a provider can be compromised. Sandbox is cheap insurance.
Sources
- MDN, the iframe element: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe
- MDN, Referrer-Policy header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy
Last reviewed: 19 October 2026.
