X-Frame-Options: DENY, SAMEORIGIN and clickjacking
X-Frame-Options controls whether other pages may put yours in a frame. DENY refuses every framing attempt, SAMEORIGIN allows only pages from your own origin.
At a glance
- Direction
- Response only, and it applies to the framed document rather than the framing one.
- Defined in
- Documented in RFC 7034. Superseded by the CSP frame-ancestors directive.
- When absent
- Any site may load your page in an iframe unless a CSP frame-ancestors directive says otherwise.
- Valid values
- DENY and SAMEORIGIN. ALLOW-FROM was never widely implemented.
- Modern equivalent
- Content-Security-Policy: frame-ancestors 'none' or 'self'
- Precedence
- Where both are present, browsers enforce frame-ancestors and ignore this header.
- In the headers checker
- Graded. It warns when the value is not one it recognises.
In detail
Clickjacking works by loading your page invisibly over something the victim wants to click, so the click lands on your interface with their session attached. X-Frame-Options is the browser side control: the framed document declares who may frame it, and the browser refuses to render it inside a frame that does not qualify.
There are only two values worth sending. DENY refuses framing by anything at all, including your own pages, and is right for anything that performs an action, such as a settings page or a payment confirmation. SAMEORIGIN allows framing by documents from the same scheme, host and port, which is what you want when your own application embeds its own pages.
ALLOW-FROM was defined to name a single permitted origin but was never supported across browsers and is ignored today. If you need to allow specific partners, that requirement can only be expressed with CSP: frame-ancestors takes a source list, so it can name several origins, which this header structurally cannot.
frame-ancestors supersedes X-Frame-Options and takes precedence wherever both appear, so a modern site sends the CSP directive and keeps this header as a short line for older clients. The two must agree: a frame-ancestors list that permits a partner while X-Frame-Options says DENY is a contradiction that behaves differently depending on which browser reads it.
Examples
X-Frame-Options: DENYContent-Security-Policy: frame-ancestors 'self' https://partner.example.com
X-Frame-Options: SAMEORIGINBrowsers that understand frame-ancestors use it and ignore the second line, so the partner is allowed only where CSP is supported.
Things that catch people out
- The header has to be on the response for the framed page. Putting it on the parent page protects nothing.
- SAMEORIGIN compares scheme, host and port, so an https page framing an http page of the same name is cross-origin and is refused.
- X-Frame-Options in a meta element is ignored entirely. It only works as a real response header.
- It says nothing about cross-origin measurement. A site that embeds you can still observe timing and sizes, so it is not a substitute for care on genuinely sensitive flows.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →Content-Security-Policy: directives, sources and reporting
How CSP directives are matched, what default-src actually falls back to, why unsafe-inline defeats the point of a policy, and how nonces and hashes work.
Cross-Origin-Opener-Policy: isolating your browsing context
What COOP severs between your page and the windows it opens, how same-origin differs from same-origin-allow-popups, and its part in cross-origin isolation.
Referrer-Policy: controlling what the Referer header leaks
Every Referrer-Policy value compared, what modern browsers do when the header is missing, and why URLs with tokens in them leak to third parties without it.
Strict-Transport-Security: the HSTS response header
What Strict-Transport-Security does, what max-age and includeSubDomains change, why preload is close to permanent, and how to withdraw the policy safely.
Permissions-Policy: turning browser features off by default
How Permissions-Policy allowlists are written, the empty parentheses that disable a feature, and how the syntax differs from the Feature-Policy header.
X-XSS-Protection: a legacy header and why it is off
What the browser XSS auditor did, why Chrome and Edge removed it, why 0 is now the recommended value, and what to send in its place.
Tools for this
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL
- htaccess Generator Free online htaccess generator - generate Apache .htaccess redirect and rewrite rules