Missing X-Frame-Options Header

What this finding means

Your site does not send an X-Frame-Options header, and no Content-Security-Policy frame-ancestors directive covers the same ground in its place. Browsers will therefore allow any other site to load your pages inside an iframe, which is the precondition for clickjacking attacks against anything on the page a user can click.

Why it matters

Without it, an attacker can embed your login page, payment form, or admin panel inside an invisible or disguised iframe on a malicious site and trick users into clicking buttons that actually act on your page — a clickjacking attack. This is especially relevant for any page with a state-changing action (login, delete, confirm, pay) that only requires a click.

What Nivaronix checks

Nivaronix's security headers checker inspects the response headers your site sends and reports whether framing is restricted at all. This is a security misconfiguration check based on the headers' presence and configuration — not a vulnerability scan, exploit attempt, or penetration test.

The check does read your Content-Security-Policy. Every current browser engine ignores X-Frame-Options outright when an enforced CSP declares frame-ancestors, so judging one header without the other would report a control as missing on a site that is protected. Three outcomes follow from that:

• X-Frame-Options is absent but an enforced CSP declares a restrictive frame-ancestors — including frame-ancestors 'none', 'self', or a named origin or host wildcard: this finding is not reported. Your site is protected, and this pairing is what our own security-headers guide tells readers to deploy.
• X-Frame-Options is absent and frame-ancestors is permissive — its whole source list is * or bare schemes such as https: — or absent entirely: this finding is reported. A directive that grants everyone is not protection.
• X-Frame-Options is present but an enforced CSP declares a permissive frame-ancestors: a separate finding, X-Frame-Options overridden by a permissive CSP, is reported instead — because the header is not missing, and adding it again would not help.

What the check does not do is grade the rest of your policy. Only the frame-ancestors directive is read.

Evidence example

Example only, for illustration — not evidence from a live scan of any specific site.

HTTP/1.1 200 OK
(no X-Frame-Options header present)
(no Content-Security-Policy frame-ancestors directive either)

# also reported — frame-ancestors is present but grants everyone:
Content-Security-Policy: frame-ancestors *

# not reported — CSP restricts framing in X-Frame-Options' place:
Content-Security-Policy: frame-ancestors 'self'

How to fix it

add_header X-Frame-Options "SAMEORIGIN" always;

Header always set X-Frame-Options "SAMEORIGIN"

Rules → Transform Rules → Modify Response Header → set `X-Frame-Options` to `SAMEORIGIN` or `DENY`.

Verify the fix

Re-run a scan on your domain, or check manually with curl -sI https://your-domain.example, and confirm X-Frame-Options now appears in the response with the expected value.

FAQ

Standards reference

MDN — X-Frame-Options. See the methodology page for exactly how this finding is scored.