Which problem the header addresses
In clickjacking, an interface misleads a person about the actual click target. For example, another site can place a permitted embedded document transparently over a visible button. The click then lands on the frame above it. Whether this leads to a harmful action depends on whether the application permits that action and whether the necessary credentials are available in the frame.
Framing rules intervene earlier: they prevent display in embedding contexts that are not allowed. This is especially relevant for account management, administration and other interactive documents. It does not protect against all interface deception, XSS or unauthorised requests outside the browser. The current processing algorithm is in the HTML Living Standard, section 7.7; the older RFC 7034 is not the sole authoritative description of it.
The Web Security Check evaluates X-Frame-Options and the visible CSP configuration of the final response after redirects. It does not crawl further pages or attempt embedding or signed-in actions. A missing header on a JSON response therefore means something different from its absence on an interactive account document.
The limits of the attack scenario
Schematic explanation · not a measurement
From embedding to a possible action
Schematic explanation · an action requires suitable authentication, permissions and application logic.
- Another site embeds the document
The browser checks the embedded document's framing policy against its ancestor chain.
This is where the framing restriction intervenes: if embedding is not permitted, the document is not displayed as a frame.
- A person clicks the overlaid target interface
Only successful embedding allows this variant's interface to mislead someone about the actual click target.
- The application checks the action
Only suitable credentials, permissions and application rules can allow an action. An additional confirmation can restrict it.
Prevent unauthorised embedding before interaction becomes possible.
The sequence has three separate steps: another site must first be allowed to embed the document. The person is then induced to click its interface. Only afterwards does the application decide whether to execute an action. A framing restriction interrupts the first step; an additional confirmation can limit the third.
SameSite cookies supplement this protection but do not replace it. If session cookies are withheld in a cross-site frame, a signed-in action may fail. However, another origin within the same site, or an application using another authentication method, remains a counterexample. Origin means scheme, host and port; site in this context combines the scheme and registrable domain. The cookie guide explains the details.
DENY, SAMEORIGIN or a partner allowlist
Choose according to the need for embedding, not a supposedly better score.
On narrow screens, scroll the table sideways.
| Intended behaviour | Response header or CSP directive | Condition |
|---|---|---|
| No embedding | X-Frame-Options: DENY or frame-ancestors 'none' | Your own embedding is also blocked. |
| Embedding only within the same origin | X-Frame-Options: SAMEORIGIN or frame-ancestors 'self' | The entire chain of ancestor documents must match. |
| Your own origin and a specific partner | frame-ancestors 'self' https://portal.example.net | Only CSP provides this explicit list. Every ancestor must belong to an allowed origin. |
https://example.com, https://shop.example.com and https://example.com:8443 are different origins. SAMEORIGIN therefore does not mean ‘all subdomains’. An arrangement of own page → external intermediate frame → own page also fails because of the external origin in the ancestor chain. CSP3: frame-ancestors
The older ALLOW-FROM value is not a suitable way to permit a partner. The current HTML algorithm treats it as an invalid single value; it does not produce a reliable embedding restriction. Multiple contradictory XFO values do not form an allowlist either. Identical duplicates and contradictory values are processed differently. Set exactly one intended value at the responsible layer.
Use CSP and X-Frame-Options together
This combination suits documents that must not be embedded at all:
Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENYThe CSP line covers only framing. Do not replace an existing complete CSP with it; add or change the directive in the responsible policy. Multiple enforced CSPs apply together and can further restrict embedding.
If the response contains an enforced frame-ancestors directive, a supporting browser ignores XFO. A permissive frame-ancestors * is therefore not rescued by a neighbouring DENY. Content-Security-Policy-Report-Only, however, does not replace XFO. An XFO fallback must also fit the intended behaviour for older clients: SAMEORIGIN can block a partner embedding there even when CSP permits it. CSP3: relationship to XFO
frame-ancestors does not work in a CSP meta element. default-src 'none' is not a substitute, because frame-ancestors has no such fallback. frame-src answers the opposite question: which frames may your own page load? The rest of the CSP configuration remains a separate subject.
Introduce, check and withdraw a rule
- Identify the relevant documents and intended embedding: your own widgets, partner portals, sign-in and payment journeys. Check nested frames too.
- Set the value in the web server, proxy, CDN or application actually responsible. Remove contradictory duplicates there; indiscriminately removing all existing protection headers is not a rollback.
- Check the response actually served with a GET. This example command shows every header block in the redirect chain; it has not been run against the placeholder address:
curl -sS -L -D - -o /dev/null https://www.example.com/konto/- Try permitted and forbidden embedding in your own test environment. Use the browser console to check whether the destination content is actually blocked by the framing policy. An empty frame can also result from network errors or the parent page's
frame-srcpolicy. - Test the required click journey and error pages. CSP Report-Only can provide signals but does not replace this functional test.
To roll back, restore the previous documented header configuration and load a new document. Documents already loaded and cached responses may retain the old state. Account for CDN and browser caches; the implementation and architecture guide explains responsibilities along the delivery path.
What this can demonstrate
You can document the intended embedding rule, the response actually served and the behaviour of the browsers and user journeys checked. This does not demonstrate comprehensive NIS2, data protection or payment card compliance. Framing headers also neither detect payment page tampering nor monitor header changes. The compliance overview distinguishes individual technical measures from broader requirements.
Frequently asked questions
What is clickjacking?
An interface misleads a person about the actual target of their interaction. In the variant discussed here, a transparent embedded document sits over visible content. Framing rules prevent unwanted embedding; a successful action additionally requires suitable credentials and application logic.
Is DENY better than SAMEORIGIN?
DENY suits documents that need no embedding. SAMEORIGIN permits your own embedding within the same origin. Either can be right; a required user journey must not break merely to obtain a stricter setting.
Is X-Frame-Options obsolete?
The header remains defined in the HTML Standard. CSP frame-ancestors provides more precise permissions and takes precedence when enforced. The former partner permission ALLOW-FROM is particularly outdated.
Are SameSite cookies enough?
They can restrict cookie-based actions in certain cross-site frames. However, they do not prevent all embedding or cover every authentication or same-site arrangement. Framing rules and cookies have different roles.
Why does the browser block my own embedded content?
First check the actual destination origin after redirects, every ancestor, both framing mechanisms and the embedding page’s frame-src policy. Only then relax the specific rule for the intended journey. A console message alone does not justify unrestricted permission.
Sources and technical reference date
- HTML Living Standard § 7.7
: current XFO processing, multiple values, ancestors and CSP precedence. - Content Security Policy Level 3 § 6.4.2
: Editor’s Draft; embedding rules, the meta-element limit and the absence of a default-src fallback.
Source reference date: 27 September 2026. The embedding counterexamples described were checked locally in Chromium 147.0.7727.15 for that source review. No customer application, full browser matrix or production server configuration was tested.