Anti-clickjacking Header
ID |
anti_clickjacking_header |
Severity |
high |
Kind |
Clickjacking |
CWE |
1021 |
Description
Clickjacking, also known as UI redress, is an attack where a malicious site embeds a target page inside a transparent or disguised iframe and tricks the user into interacting with it unknowingly. When a web application does not set proper anti-clickjacking headers, any external site can frame its pages, enabling an attacker to overlay invisible controls that capture user clicks.
This detector flags responses that are missing or misconfiguring the protections provided by the X-Frame-Options header and the Content-Security-Policy frame-ancestors directive.
-
Scenario 1: Missing Anti-clickjacking Header. The response includes neither a Content-Security-Policy header with the frame-ancestors directive nor an X-Frame-Options header, leaving the page completely unprotected against framing by arbitrary origins.
-
Scenario 2: Multiple X-Frame-Options Header Entries. The response contains more than one X-Frame-Options header. RFC 7034 does not define behavior for duplicate entries, so different browsers may interpret them inconsistently, potentially ignoring the restriction altogether.
-
Scenario 3: X-Frame-Options Defined via META Tag (Non-compliant with Spec). An X-Frame-Options value was set inside an HTML meta element instead of an HTTP response header. RFC 7034 explicitly states that the directive is only honored as an HTTP header, so the meta tag has no protective effect.
-
Scenario 4: X-Frame-Options Setting Malformed. An X-Frame-Options header is present but its value is not a recognized token such as DENY or SAMEORIGIN. Browsers that encounter an unrecognized value may silently ignore the header, leaving the page unprotected.
Rationale
A successful clickjacking attack can lead users to perform sensitive actions without their knowledge, such as changing account settings, authorizing financial transactions, toggling security permissions, or granting access to devices like webcams and microphones. Because the victim believes they are clicking on a legitimate element of a trusted page, the attack bypasses conventional awareness of phishing and social-engineering techniques.
The risk is amplified on pages that execute state-changing operations (form submissions, OAuth authorizations, preference toggles), where a single invisible click is enough to cause damage.
Remediation
Set the Content-Security-Policy header with a frame-ancestors directive on every response. Use frame-ancestors 'none' if the page should never be framed, or frame-ancestors 'self' if it only needs to be framed by the same origin. This is the modern, standards-based defense and takes precedence over X-Frame-Options in browsers that support it.
For backward compatibility with older browsers, also include the X-Frame-Options header. Set it to DENY when framing is never needed, or to SAMEORIGIN when same-origin framing is required. Do not rely on the obsolete ALLOW-FROM directive, as it is no longer honored by current browsers.
Ensure that the header is applied as an HTTP response header, not inside an HTML meta tag, and that only a single X-Frame-Options header is present per response to avoid ambiguous browser behavior.