Iframes use sandbox attribute
Why it matters
An iframe without a sandbox attribute inherits the full capabilities of the embedding page: it can run scripts, submit forms, navigate the top frame, and access storage. A compromised or malicious embedded resource (ads, widgets, user-generated embeds) can exploit unrestricted iframes to navigate your page to a phishing URL, submit forms on the user's behalf, or read cross-origin storage if the embed is same-site. CWE-1021 (Improper Restriction of Rendered UI Layers) applies directly. OWASP A05 identifies unsandboxed iframes as a configuration gap that gives embedded third-party content unwarranted trust.
Severity rationale
Low because exploitation requires a compromised or malicious embed, but the `sandbox` attribute is a zero-cost capability restriction that eliminates the entire attack surface for misbehaving embeds.
Remediation
Add the sandbox attribute to every <iframe> element. Start with no permissions and add only those the embed actually requires.
{/* Video embed — needs scripts only */}
<iframe src="https://player.example.com/embed/123" sandbox="allow-scripts" />
{/* Interactive widget needing forms */}
<iframe src="https://widget.example.com" sandbox="allow-scripts allow-forms" />
{/* Same-origin embed needing full interaction */}
<iframe src="/embed/preview" sandbox="allow-scripts allow-same-origin allow-forms" />
Avoid allow-same-origin combined with allow-scripts for cross-origin iframes — that combination effectively defeats sandboxing by letting the embed escape via same-origin DOM access.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Security Headers II Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-1021
- owasp:2021 · A05
Taxons
History
- 2026-04-18·v1.0.0·Initial import from security-headers-ii·automated