🖼️ Security

X-Frame-Options vs frame-ancestors Compare

Compare X-Frame-Options with the CSP frame-ancestors directive and detect conflicts or redundancy for clickjacking.

X-Frame-Options (empty = absent) CSP frame-ancestors (empty = absent) Behaviour and recommendation

—

X-Frame-Options or frame-ancestors: which one wins

Clickjacking works by placing your page inside an invisible iframe over other content, so that the visitor's click lands on your button without them noticing. The two defences are the older X-Frame-Options header and the modern frame-ancestors directive of Content-Security-Policy. Almost every site ends up with both configured, and not always with matching values.

Enter what each one is sending and the page translates the meaning of every value and says which prevails. The rule is simple: when frame-ancestors is present, a modern browser ignores X-Frame-Options entirely. XFO only still applies where CSP is not interpreted, which today means genuinely old browsers. Contradictory values produce no error — they produce behaviour that varies by browser.

The equivalences are worth knowing: DENY corresponds to frame-ancestors with none, and SAMEORIGIN corresponds to frame-ancestors self. What has no equivalent is ALLOW-FROM, which never worked properly and is ignored by Chrome and Firefox — anyone needing to allow a specific partner can only do it through frame-ancestors, which takes a list of origins.

Frequently asked questions

Do I need to keep both headers?

Keeping XFO costs almost nothing and covers old clients, so common practice is sending both with equivalent values. What does not work is sending only XFO and calling it modern, nor sending values that contradict each other, because then behaviour depends on which of the two the client understands.

How do I allow just one partner to embed my page?

With frame-ancestors followed by their origin, and only that — ALLOW-FROM is not an option because current browsers discard it. Remember the directive takes several space-separated origins, and that matching is by full origin: scheme, host and port.

Does the CSP meta tag work for this?

No. frame-ancestors is explicitly ignored when the policy arrives through a meta tag — the decision to allow framing happens before the HTML is processed. That directive only works in a real HTTP header.

Related Tools

🔒

Content-Security-Policy Builder

Build a Content-Security-Policy header by adding directives (default-src, script-src, img-src, frame-ancestors) with predefined sources.

🛡️

Basic CSP Evaluator

Evaluates a Content-Security-Policy directive reporting unsafe-inline, unsafe-eval or wildcard issues.

🔏

CSP Hash Generator for Inline Scripts

Generate the SHA-256/384/512 base64 hash of an inline script to allow it in your Content-Security-Policy (CSP) without using a nonce. Harden your site security.

📄

X-Content-Type-Options Header Check

Confirm X-Content-Type-Options is set to nosniff and explain MIME-sniffing risks when the header is missing.

🛂

CORS Preflight Explainer

Given a CORS request method and headers, shows whether it triggers an OPTIONS preflight and explains why.

🛡️

Trusted Types Policy Builder

Generate CSP require-trusted-types-for and trusted-types directives with policy names — a modern anti-XSS mitigation.