Missing X-Frame-Options Header (Clickjacking)

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Security Misconfiguration / UI Redress Attack
Typical Severity Medium
OWASP A05:2021 – Security Misconfiguration
CWE CWE-1021: Improper Restriction of Rendered UI Layers or Frames
Also known as Clickjacking, UI Redress Attack, iframe Overlay Attack
Affected systems Any web application that does not set X-Frame-Options or CSP frame-ancestors on its HTTP responses
Relevant standard RFC 7034 (X-Frame-Options), W3C CSP Level 2 (frame-ancestors)

Overview

The X-Frame-Options HTTP response header instructs browsers whether a page may be rendered inside a <frame>, <iframe>, <embed>, or <object> element. When this header is missing — and no equivalent Content-Security-Policy: frame-ancestors directive is present — the page can be embedded by any third-party origin, enabling clickjacking (also called UI redress) attacks.

In a clickjacking attack, the adversary loads the victim page invisibly inside an iframe on a malicious site, then overlays deceptive UI elements to trick the user into clicking buttons or links on the hidden page without awareness.

How it works

The attack exploits the browser's default permissiveness toward cross-origin framing:

  1. Attacker constructs a malicious page that loads the target application in a transparent or zero-opacity <iframe> positioned precisely over a convincing decoy UI.
  2. User is lured to the malicious page via phishing, a malicious ad, or a compromised third-party site.
  3. User interacts with what appears to be the decoy interface (e.g., a "Play" button or a prize claim form), but the click is captured by the overlaid iframe and triggers an authenticated action on the target application (e.g., transferring funds, changing account email, granting OAuth permissions).
  4. Because the request originates from the user's authenticated session, server-side controls such as CSRF tokens may still be satisfied.

Key technical points:

  • X-Frame-Options: DENY — prevents all framing regardless of origin.
  • X-Frame-Options: SAMEORIGIN — allows framing only by pages on the same origin.
  • X-Frame-Options: ALLOW-FROM uri — allows a single specified origin (deprecated; inconsistently supported and superseded by CSP).
  • The modern, preferred mechanism is Content-Security-Policy: frame-ancestors 'none' or frame-ancestors 'self', which offers finer-grained control and is defined by the W3C CSP Level 2 specification.
  • Frame-busting JavaScript (attempting to break out of iframes via top.location checks) is an unreliable mitigation: it can be defeated by the sandbox attribute on the iframe or by disabling JavaScript.
  • Not all pages carry the same risk; pages that perform sensitive state-changing operations (authentication, account management, payments) are highest priority.

Business impact

Successful clickjacking exploits can result in:

  • Unauthorised account actions — password changes, email address changes, two-factor authentication disablement, or deletion of account data performed silently on behalf of the victim.
  • Financial fraud — initiating wire transfers, purchases, or subscription changes on banking and e-commerce platforms.
  • Privilege escalation — tricking an administrator into approving elevated permissions or disabling security controls in an admin panel.
  • Credential or token harvesting — combined with form injection techniques, attackers can harvest credentials submitted into overlaid forms.
  • Regulatory exposure — under GDPR, PCI DSS, and similar frameworks, failure to implement basic security controls can constitute negligence and attract fines or audit findings.
  • Reputational damage — user trust is eroded when accounts are compromised due to foreseeable, preventable weaknesses.

How to fix it

  1. Set X-Frame-Options on all responses (minimum viable fix):
    Add the header at the web server or application layer. Use DENY unless there is a specific need for same-origin framing: 
    X-Frame-Options: DENY
    or, if the application legitimately frames itself: 
    X-Frame-Options: SAMEORIGIN
  2. Prefer Content-Security-Policy: frame-ancestors (recommended):
    This directive supersedes X-Frame-Options in all modern browsers, supports multiple trusted origins, and is the W3C-standardised approach: 
    Content-Security-Policy: frame-ancestors 'none';
    or 
    Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.example.com;
    Deploying both headers provides defence in depth for older browsers that do not support CSP.
  3. Configure at the infrastructure layer:
    Apply the header globally in reverse proxy or load balancer configuration (nginx, Apache, IIS, CDN edge rules) rather than relying solely on application code, to ensure consistent coverage including error pages and static assets.
    • nginx: add_header X-Frame-Options "DENY" always;
    • Apache: Header always set X-Frame-Options "DENY"
    • IIS: Add a custom HTTP response header via web.config or the IIS Manager UI.
  4. Audit legitimate framing requirements:
    If the application must be embeddable (e.g., a widget or embedded payment form), enumerate all legitimate parent origins explicitly in frame-ancestors rather than using a wildcard (*), which provides no protection.
  5. Include sensitive sub-pages:
    Ensure the header is present not only on the home page but on all authenticated, state-changing endpoints including account settings, checkout flows, and admin interfaces.
  6. Test the fix:
    Verify the header appears on HTTP responses using browser developer tools (Network tab) or a command-line check: curl -I https://example.com. Sensagraph continuously monitors for this header across your web properties and flags pages where it is absent.

References

Frequently asked questions

X-Frame-Options is an older, widely supported header defined in RFC 7034 with three directives: DENY, SAMEORIGIN, and the deprecated ALLOW-FROM. Content-Security-Policy frame-ancestors is the modern W3C-standardised replacement that supports multiple allowed origins and is more flexible. In browsers that support CSP (all modern browsers), frame-ancestors takes precedence over X-Frame-Options. Deploying both headers provides the broadest browser coverage.

No. Any user interaction on a framed page can be hijacked, including link clicks, drag-and-drop operations, and even scroll events in some attack variants. However, sensitive state-changing endpoints such as account settings, payment flows, and administrative actions are the highest-value targets because a single misdirected click can have significant consequences.

No. HTTPS encrypts data in transit and authenticates the server, but it does not prevent a browser from rendering a page inside an iframe on a third-party origin. Clickjacking operates entirely at the browser UI layer and is independent of the transport security mechanism.

Not reliably. CSRF tokens protect against cross-site request forgery by verifying that a request originated from a legitimate form on the target site. In a clickjacking attack, the victim's browser genuinely loads the target page in an iframe and submits a real form with a valid CSRF token — the token check is satisfied, so it provides no additional protection against clickjacking.

Severity depends on the context of the affected page. For unauthenticated, purely informational pages it is typically Low. For authenticated pages that perform state-changing operations (account management, payments, admin functions), it is generally rated Medium to High due to the ease of exploitation and potential impact. Security scanners typically default to Medium as a conservative baseline.