URI Fragment-based iframe Source Hijack (DOM-based)
Description
Client-side JavaScript reads the URI fragment (location.hash) and uses its value — often after base64-decoding it — to set the source of a frame-like element (iframe, frame, embed, or object) with no validation of the resulting origin. Because the fragment is never sent to the server, an attacker can craft a link to the trusted, legitimate page whose fragment points the frame at attacker-controlled content. The victim sees the trusted origin in the address bar while arbitrary content is rendered inside the page. This is a distinct, higher-impact issue from the standard "Insecure Frame (External)" finding (a missing sandbox attribute): here the frame destination itself is attacker-controlled via the fragment, which is invisible to server logs and web application firewalls.
Remediation
Never derive a frame source from the URI fragment without validating the resulting URL.
1. Validate against an allowlist: parse the (decoded) value and permit only URLs whose origin appears on an explicit allowlist of trusted origins; reject everything else.
const ALLOWED = ['https://maps.example.com', 'https://embed.example.com'];
function safeFrameSrc(candidate) {
try {
const u = new URL(candidate, location.origin);
return ALLOWED.includes(u.origin) ? u.href : null;
} catch (e) { return null; }
}2. Prefer same-origin, relative destinations: if the framed content is first-party, restrict the value to a relative path and resolve it against your own origin.3. Do not trust the fragment for security decisions: treat location.hash as fully attacker-controlled input.
4. Add defense in depth: apply a Content-Security-Policy with a restrictive
frame-src directive so the browser refuses to load framed content from unexpected origins even if a sink is missed.