Frame busting is a security technique that prevents a web page from being embedded within an iframe on another site, helping prevent clickjacking attacks. While traditional frame busting used JavaScript, modern approaches rely on the X-Frame-Options header or CSP frame-ancestors directive. This protection is crucial for sites handling sensitive actions or data.
Frame-busting (or frame-breaking) is the practice of preventing a page from being displayed inside another site's iframe, the core defense against clickjacking. The original technique was JavaScript that checked whether the page was the top-level window, for example comparing window.top to window.self, and if not, forced navigation to break out of the frame or hid the body. This client-side approach worked but proved fragile: attackers used sandboxed iframes, the beforeunload event, restrictive framing, and other tricks to defeat naive scripts. Modern frame-busting has largely moved from JavaScript to declarative, server-set HTTP headers that the browser enforces before the page even renders.
How you bust frames determines whether the protection actually holds. Script-based busting runs only after the page begins loading and can be suppressed, delayed, or sandboxed away, and it fails entirely if the user has JavaScript disabled or an extension interferes. Header-based busting is evaluated by the browser at load time and cannot be scripted around by the framing page, so it is strictly more reliable. Getting this right matters because the pages most worth framing, banking flows, admin actions, OAuth consent, are exactly the ones where a bypassed frame-buster turns into account takeover or unauthorized transactions through clickjacking.
Prefer declarative headers over scripts. Set Content-Security-Policy: frame-ancestors with an explicit allowlist of origins permitted to embed you, or 'none' to forbid framing entirely, and add X-Frame-Options: DENY or SAMEORIGIN to cover older browsers. Keep any JavaScript fallback only as defense in depth, never as the sole control. Verify the headers ship on every sensitive route, including error pages. Because these are secure headers delivered with your responses, a compromised or misbehaving third-party script that alters or removes them undermines the protection; cside's runtime monitoring can detect when framing headers are stripped or weakened so the defense stays intact in production.
Use both. CSP frame-ancestors is the modern directive, supports multiple allowed origins, and supersedes X-Frame-Options in browsers that honor it. X-Frame-Options (DENY or SAMEORIGIN) remains a useful fallback for older clients that lack frame-ancestors support. Sending both maximizes coverage.
It executes only after the page loads and depends on JavaScript being enabled and uninterrupted. Attackers can neutralize it with sandboxed iframes, the onbeforeunload event, or double-framing tricks. Header-based framing controls are enforced by the browser before rendering, so they cannot be scripted around by the embedding page.
We answer client-side security questions every day. Bring yours.