http.clickjacking_protection Reviewed July 2026

Quick fix

Define CSP `frame-ancestors` with `'none'`, `'self'`, or an explicit allowlist.

What this finding means

SecuTest accepts CSP `frame-ancestors` or `X-Frame-Options: DENY/SAMEORIGIN`. CSP is the modern control; X-Frame-Options remains useful for older clients. The check does not prove that every page contains a sensitive action.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Clickjacking and UI redress

How the attack or failure scenario works

Clickjacking overlays or hides a trusted page inside an attacker-controlled frame. The victim believes they are clicking the attacker's interface but actually activates controls in the framed application, potentially changing settings, authorizing actions, or disclosing information.

Conditions and limitations

  • The application can be embedded by an attacker-controlled origin.
  • The victim is authenticated or otherwise has access to a meaningful action.
  • The attacker can align deceptive content with the framed control and the application lacks additional confirmation defenses.

Why it matters

Security and business impact Without `frame-ancestors` or a valid X-Frame-Options value, another site may frame the application and trick users into interacting with hidden controls.

Step-by-step fix

Where to make the change

  • The outermost component emitting the public HTTP response: CDN, reverse proxy, ingress, web server, or application middleware.
  • Apply the control consistently to normal pages, redirects, error responses, and relevant subdomains.

Remediation procedure

  1. Define CSP `frame-ancestors` with `'none'`, `'self'`, or an explicit allowlist.
  2. Add `X-Frame-Options: DENY` or `SAMEORIGIN` for legacy compatibility when it matches the intended policy.
  3. Require re-authentication or explicit confirmation for high-impact actions.
  4. Test every legitimate embedding integration before enforcing a restrictive policy.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

CSP preferred
Content-Security-Policy: frame-ancestors 'none'

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

Apache
Header always set Content-Security-Policy "frame-ancestors 'none'"
Header always set X-Frame-Options "DENY"

Verify the fix

  1. Inspect CSP and X-Frame-Options on normal and error responses.
  2. Attempt to embed the page from an unrelated test origin and confirm the browser blocks it.
  3. Test authorized same-origin or partner framing where required.
  4. Verify that CSP is delivered as a response header, not only a meta element.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Using `ALLOW-FROM`, which has poor browser support.
  • Allowing all framing to support one partner instead of explicitly allowlisting it.
  • Relying on JavaScript frame-busting code as the primary control.

Authoritative references