Clickjacking Guide: Frame Protection with CSP and X-Frame-Options

Clickjacking tricks a user into clicking or tapping a control on your page while they believe they are interacting with something else, so a real, authenticated action happens without informed consent. It is also called UI redressing, and its mobile form is tapjacking. The core defence is simple, a single response header, yet it is routinely missing from login, consent, settings and error pages. This guide explains how framing attacks and newer non-framing variants work, where protection usually breaks, and how to roll out frame-ancestors and X-Frame-Options without breaking legitimate embeds. It is for developers, platform engineers and application security testers. Header syntax for the whole security header set is in the Security Headers Guide; this page goes deeper on framing.

Key takeaways

• Send Content-Security-Policy: frame-ancestors 'none' by default. OWASP recommends it unless a specific framing need exists, and ASVS 5.0 V3.4.6 requires frame-ancestors on every response.
• Keep X-Frame-Options only as a fallback. Use DENY or SAMEORIGIN; ALLOW-FROM is obsolete and modern browsers ignore the whole header when they see it.
• Headers, not meta tags. Neither frame-ancestors nor X-Frame-Options works in a <meta> element.
• Framing headers do not stop every UI redress. DoubleClickjacking targets a top-level window, so high-risk actions also need server-side transaction authorisation.
• Frame-busting JavaScript is a legacy fallback. Sandboxed iframes, double framing and navigation cancelling defeat it.

How the attack works

MITRE CWE-1021, Improper Restriction of Rendered UI Layers or Frames, covers an application that does not restrict, or incorrectly restricts, frames or UI layers belonging to another application or domain. CAPEC-103 (Clickjacking) and CAPEC-222 (iFrame Overlay) describe the attack patterns, and CAPEC-506 covers tapjacking.

1. Embed: an attacker-controlled page loads the target page in an <iframe> (or <object> or <embed>).
2. Disguise: the frame is made invisible or covered with decoy content, so the user sees a game, a video player or a "continue" button.
3. Align: a sensitive control on the hidden page, such as "Delete", "Allow" or "Confirm transfer", sits under the decoy.
4. Click: the user clicks the decoy and the browser delivers the click to the real page, which acts with whatever session the browser holds.

Unlike CSRF, the request comes from your own page in its own origin, so anti-CSRF tokens on the form are present and valid. CSRF is a separate class with its own controls.

Variants

Where it shows up

• Consent and permission screens: OAuth "Allow" pages, browser permission prompts relayed by the app, connect-an-integration dialogs. A framed consent grant can hand a third party a token. See the Consent Phishing and Illicit OAuth Grants Guide.
• Account settings: email, recovery options, MFA disable, privacy and sharing toggles. CWE-1021 cites changed privacy settings in a social application as an example impact.
• Admin and device consoles: CWE-1021's observed examples include a hardware product's web interface (CVE-2017-5697) and a data-loss prevention product (CVE-2017-4015).
• Pages outside the main template: error pages, static pages served by a CDN, legacy subpaths and mobile variants. WSTG-CLNT-09 calls out mobile and accessibility versions as places where headers are missing.
• Behind proxies: WSTG and the OWASP cheat sheet both note that a proxy can strip the framing header and silently remove protection.
• Legitimately embeddable pages: widgets, payment fields and dashboards designed to be framed. These need a precise allow-list rather than no policy.

Impact

CWE-1021 lists gaining privileges or assuming identity, bypassing protection mechanisms and reading or modifying application data. Impact depends entirely on what the framed page lets an authenticated user do.

The identity angle: consent screens and key-creation buttons are where a human click becomes a non-human identity. Treat those pages as the highest-priority framing targets.

Detection

• Header coverage scanning: crawl every route, including login, error, API documentation and static paths, and record the effective frame-ancestors and X-Frame-Options values. One-URL scans miss most gaps.
• Framing test: WSTG-CLNT-09 describes loading the page in a test iframe from another origin; if it renders, it is likely vulnerable. Repeat for mobile and accessibility variants.
• CSP violation reports: frame-ancestors violations reported through CSP reporting show which origins try to embed you, both partners you forgot and hostile sites.
• Edge configuration drift: alert when a CDN, WAF or reverse proxy rule removes or overrides the header.
• Sensitive action telemetry: for consent grants and key creation, record Sec-Fetch-Dest where available and investigate requests from iframe destinations to pages that should never be framed.

Metrics

• Percentage of HTML responses with an enforced frame-ancestors directive (target: 100 percent).
• Number of routes allowing framing, each with an owner and an explicit origin list.
• Responses still using ALLOW-FROM or meta-tag framing controls (target: zero).
• High-risk actions protected by server-side transaction authorisation, as a share of the inventory.
• Time to detect a header removed by an edge configuration change.

Prevention and hardening

Comparing the controls

Choosing a policy

• Never embedded (most pages): frame-ancestors 'none' plus X-Frame-Options: DENY.
• Embedded only by your own pages: frame-ancestors 'self' plus X-Frame-Options: SAMEORIGIN. Remember SAMEORIGIN in modern browsers requires every ancestor to share the origin.
• Embedded by named partners: frame-ancestors with exact origins, for example 'self' https://portal.partner.example. Omit X-Frame-Options on these routes or browsers lacking CSP support will block the partner; accept that trade-off consciously.
• Embeddable widgets on arbitrary sites: keep the widget free of sensitive actions; send state changes to a top-level window you control, protected with frame-ancestors 'none'.

Small organisations get most of the benefit from one site-wide header set at the web server or CDN. Large estates should set the default centrally and let individual routes relax it through a reviewed exception list, so a new page is protected without anyone remembering to add a header.

Implementation sequence

1. Inventory embeds: list every page legitimately framed, by which origin, from CSP reports and partner contracts.
2. Set the default centrally: add frame-ancestors 'none' and X-Frame-Options: DENY at the server, framework middleware or edge so every HTML response, including errors, carries them.
3. Test in report-only: deploy Content-Security-Policy-Report-Only with the frame-ancestors policy first and review reports for legitimate parents. Keep an existing X-Frame-Options in place meanwhile.
4. Add exceptions: relax only listed routes to exact origins; remove any ALLOW-FROM and meta-tag attempts.
5. Enforce: switch to the enforcing header, then re-run the WSTG-CLNT-09 framing test across desktop, mobile and accessibility variants.
6. Protect high-risk actions: add server-side transaction authorisation for consent, key creation, MFA changes and payments.
7. Mobile apps: set filterTouchesWhenObscured on sensitive views and call Window.setHideOverlayWindows(true) on Android 12 (API 31) and later; Android 12 also blocks untrusted overlay touches by default. See the Mobile App Security Guide.
8. Rollback: if a partner embed breaks, add its exact origin to that route's policy rather than removing the header site-wide.

Supplementary measures

• Frame-busting: if legacy clients matter, use the OWASP pattern that hides the page until it confirms it is top-level. OWASP does not recommend the simple top.location redirect script alone.
• Confirmation dialogs: OWASP calls window.confirm() supplementary confirmation, not a guarantee, because sandboxed frames without allow-modals suppress dialogs; act only on a true result.
• Disabled-until-interaction controls: a proposed DoubleClickjacking mitigation. Keep controls usable by keyboard, touch and assistive technology, as OWASP warns against designs that block some users.

Common failure patterns

• Header on the app, not the edge: error pages, redirects and CDN-served HTML skip the application middleware and go out unprotected.
• Meta-tag policies: teams add a <meta> CSP or X-Frame-Options and believe they are protected; browsers ignore both for framing.
• ALLOW-FROM left in place: OWASP warns it can fail open, leaving no clickjacking defence at all in modern browsers.
• Wildcard partner lists: https://*.example.com lets any subdomain, including a forgotten or taken-over one, frame sensitive pages.
• Assuming SameSite covers it: OWASP states SameSite does not block framing, and pages that need no login get no protection.
• Header only on the homepage: compliance scans check one URL while consent and settings pages lack the policy.

Framework mapping

Practitioner checklist

• Send frame-ancestors 'none' by default on every HTML response, including error and static pages.
• Keep X-Frame-Options: DENY or SAMEORIGIN as a fallback where no partner framing is needed.
• Remove ALLOW-FROM and any meta-tag framing controls.
• Maintain a reviewed list of routes that may be framed, with exact origins and owners.
• Roll out changes with Content-Security-Policy-Report-Only and monitor violation reports.
• Verify that CDNs, WAFs and proxies preserve the headers.
• Add server-side transaction authorisation to consent, key creation, MFA and payment actions.
• Set session cookies with explicit SameSite as defence in depth.
• Protect sensitive Android views against overlays.
• Test desktop, mobile and accessibility variants with WSTG-CLNT-09.

Standards and references

• OWASP: Clickjacking Defense Cheat Sheet
• MITRE: CWE-1021 Improper Restriction of Rendered UI Layers or Frames
• OWASP: Application Security Verification Standard 5.0
• MDN: CSP frame-ancestors
• MDN: X-Frame-Options
• IETF: RFC 7034 HTTP Header Field X-Frame-Options
• OWASP: WSTG Testing for Clickjacking
• Android Developers: Tapjacking

Related NHI Mgmt Group resources: Security Headers Guide · Web Application Attacks Guide · Client-Side Security Guide · Web Application Security Testing Guide