Remediation guide

X-Frame-Options vs CSP frame-ancestors: Which Do You Need?

Security scanners often flag two separate clickjacking findings on the same site: a missing X-Frame-Options header, and a Content-Security-Policy header without a frame-ancestors directive. They protect against the same attack — so which one do you actually need to set? This guide explains what each one does, how browser precedence works when both are present, and the exact snippets to deploy on every major platform.

• What X-Frame-Options does
• What frame-ancestors does
• Key differences
• Precedence: what wins
• What to set
• Platform snippets
• Verify with HardenCheck
• FAQ

What X-Frame-Options does

The X-Frame-Options (XFO) response header, first shipped in browsers around 2009, prevents your page from being loaded inside a <frame>, <iframe>, or similar embedding element on a different site. The attack it guards against is clickjacking: an attacker loads your page invisibly in an iframe, lays their own UI on top, and tricks users into clicking buttons they can’t see — confirming a payment, deleting an account, changing a password.

The header has exactly two useful values in 2026:

The header for most sites is simply:

X-Frame-Options: DENY

What CSP frame-ancestors does

The frame-ancestors directive is part of Content Security Policy Level 2 (2015). It controls which origins can embed your page in a <frame>, <iframe>, <embed>, or <object> element. It supersedes X-Frame-Options in all browsers that support CSP, and it provides expressive power that XFO never had.

Common values:

# Block all framing (equivalent to XFO: DENY)
Content-Security-Policy: frame-ancestors 'none'

# Allow same-origin only (equivalent to XFO: SAMEORIGIN)
Content-Security-Policy: frame-ancestors 'self'

# Allow same-origin plus one trusted partner
Content-Security-Policy: frame-ancestors 'self' https://partner.example.com

# Allow any subdomain of your own domain
Content-Security-Policy: frame-ancestors 'self' https://*.yoursite.com

The directive is typically included alongside your other CSP rules:

Content-Security-Policy: default-src 'self'; script-src 'self'; frame-ancestors 'none'

Key differences at a glance

Precedence: what happens when both headers are present

The CSP specification is clear: when a browser supports CSP Level 2 and a response contains both X-Frame-Options and a Content-Security-Policy: frame-ancestors directive, the browser uses frame-ancestors and ignores X-Frame-Options. This is the behaviour in Chrome, Firefox, Edge, and Safari.

Internet Explorer does not support CSP at all. When IE receives both headers, it reads X-Frame-Options and ignores the entire Content-Security-Policy header. This is the sole remaining reason to set X-Frame-Options — it is the only clickjacking protection IE recognises.

Crucially, setting both headers with consistent values — DENY paired with 'none', or SAMEORIGIN paired with 'self' — creates no conflict. Modern browsers use frame-ancestors; IE falls back to XFO. The two headers target different browser generations and complement each other cleanly.

What to set in 2026

The recommended approach is belt-and-suspenders: include frame-ancestors in your CSP, and also send X-Frame-Options. They do not conflict, and together they cover every browser from IE 9 to Chrome latest.

For a site with no legitimate embedding use case (the vast majority):

X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; ...; frame-ancestors 'none'

For a site that embeds its own pages in iframes:

X-Frame-Options: SAMEORIGIN
Content-Security-Policy: default-src 'self'; ...; frame-ancestors 'self'

For a site that allows embedding by a trusted partner (XFO alone cannot express this):

X-Frame-Options: SAMEORIGIN
Content-Security-Policy: default-src 'self'; ...; frame-ancestors 'self' https://dashboard.partner.com

In this third case, modern browsers use frame-ancestors and allow the partner. IE uses SAMEORIGIN and blocks the partner — but IE has less than 1% global usage as of 2026, so this is an acceptable tradeoff. IE also cannot render your modern JavaScript application, making this moot in practice.

Add the headers on your platform

The snippets below add both headers. If you already have a Content-Security-Policy header, append ; frame-ancestors 'none' to the existing value instead of duplicating the header line.

nginx

add_header X-Frame-Options "DENY" always;
add_header Content-Security-Policy "frame-ancestors 'none'" always;

Apache (.htaccess)

<IfModule mod_headers.c>
  Header always set X-Frame-Options "DENY"
  Header always append Content-Security-Policy "frame-ancestors 'none'"
</IfModule>

Vercel (vercel.json)

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "Content-Security-Policy", "value": "frame-ancestors 'none'" }
      ]
    }
  ]
}

Next.js (next.config.js)

const securityHeaders = [
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'Content-Security-Policy', value: "frame-ancestors 'none'" }
];

module.exports = {
  async headers() {
    return [{ source: '/(.*)', headers: securityHeaders }];
  },
};

Netlify (_headers file)

/*
  X-Frame-Options: DENY
  Content-Security-Policy: frame-ancestors 'none'

Cloudflare Pages (_headers file)

/*
  X-Frame-Options: DENY
  Content-Security-Policy: frame-ancestors 'none'

Verify with HardenCheck

Paste your raw HTTP response headers into HardenCheck after deploying. It reads both X-Frame-Options and the frame-ancestors directive inside your Content-Security-Policy. If your CSP has a valid frame-ancestors value, HardenCheck treats your framing protection as satisfied even if X-Frame-Options is absent, since modern browsers will use frame-ancestors. The paste mode — using output from curl -I https://your-site.com — is the most accurate way to confirm what your server is actually sending.

Grade my headers with HardenCheck →

Frequently asked questions

Also in the Copper Bay Labs ship-safety suite

Framing protection is one layer — these tools and guides cover the rest: