How to fix x frame options weak on Headless / Custom (I build in code)

Steps for Headless / Custom (I build in code)

1. For Node.js / Express: use the 'helmet' npm package — app.use(helmet.frameguard({ action: 'deny' })) — which sets X-Frame-Options: DENY and you can separately add a CSP header with frame-ancestors 'none'.
2. For Next.js: add headers to next.config.js in the headers() async function (see code snippet below).
3. For Vercel deployments: add a vercel.json file to your project root with a headers array entry for X-Frame-Options: DENY (see code snippet below).
4. For Netlify deployments: add a netlify.toml file with a [[headers]] block, or add a _headers file to your publish directory (see code snippet below).
5. For Apache: add to .htaccess — Header always set X-Frame-Options "DENY"
6. For Nginx: add to server{} block — add_header X-Frame-Options "DENY" always;
7. Always pair X-Frame-Options with Content-Security-Policy: frame-ancestors 'none'; for full modern browser coverage.
8. Verify with: curl -I https://yourdomain.com | grep -i -E 'x-frame|content-security'

What is x frame options weak?

The `X-Frame-Options` HTTP response header tells browsers whether your website is allowed to be loaded inside an `<iframe>`, `<frame>`, or `<object>` on another site. There are two safe values: `DENY` (no framing allowed anywhere) and `SAMEORIGIN` (only your own site can frame your pages). A third value, `ALLOW-FROM`, was once supported to whitelist a specific external domain — but it is now obsolete, ignored by most modern browsers, and therefore provides no real protection. When this header is missing, set to an unsupported value like `ALLOW-FROM`, or combined with `SAMEORIGIN` in a way that browsers parse inconsistently, your pages are effectively unprotected against framing by attackers.

Without a properly enforced `X-Frame-Options` header, attackers can silently embed your store's checkout, login, or account pages inside invisible iframes on malicious websites — a technique called clickjacking. A shopper thinks they're clicking a button on the attacker's page, but they're actually clicking your hidden iframe: entering payment details, changing account settings, or completing unwanted purchases. This is a real theft and fraud vector that can lead to chargebacks, customer complaints, regulatory scrutiny under PCI-DSS, and loss of consumer trust. Search engines like Google also consider security posture signals when evaluating site quality; a site known to be compromised through clickjacking can suffer ranking and reputation damage. Fixing this header takes under 30 minutes and closes the vulnerability entirely for all modern browsers.

See the complete X frame options weak guide for every platform and the full background.