Vulnerability library  /  Clickjacking
CWE-1021OWASP A04:2021 Insecure Design

Clickjacking

Clickjacking

Clickjacking places a trusted page inside a deceptive frame so the user clicks or types into controls they cannot clearly see. It can turn an ordinary authenticated action into an unintended change.

Also known as
UI redressing · User interface redress attack · Frame overlay attack
Typical severity · Low to High
Last updated
On this page: What it is
  1. 1 · What it is
  2. 2 · Why it matters
  3. 3 · Examples
  4. 4 · How to fix it
  5. 5 · How to test for it
  6. References
  7. Related

What it is#

Clickjacking occurs when an attacker embeds a legitimate application page in an invisible or disguised frame and positions deceptive content over it. The victim believes they are interacting with the attacker's page while their clicks reach the framed application.

Because the browser may include the victim's authenticated cookies in the frame, the action can execute with the victim's privileges. Variants target drag-and-drop, touch input, copied data, or repeated clicks.

The main defense is for the trusted application to declare who may frame it. JavaScript frame-busting code is unreliable because it can be blocked, raced, or bypassed by browser and sandbox behavior.

Why it matters#

  • Trigger account-setting, consent, purchase, workflow, or administrative actions.
  • Trick users into authorizing access, enabling a feature, or changing a security control.
  • Capture data typed into a visually disguised framed form.
  • Abuse authenticated staff sessions against internal or administrative applications.
  • Combine with CSRF weaknesses, predictable interfaces, or missing reauthentication.
Typical severity

Usually low to medium. High when a small number of predictable clicks can change credentials, authorize access, move value, publish data, or perform an administrative action. Actual severity depends on context: who is affected, what data or actions are reachable, and existing controls.

Examples#

✕ Vulnerablenginx
# Vulnerable: sensitive pages can be framed by any origin.
location /account/ {
    proxy_pass http://portal;
}
✓ Fixednginx
# Fixed: modern CSP plus a compatible legacy header.
location /account/ {
    add_header Content-Security-Policy "frame-ancestors 'none'" always;
    add_header X-Frame-Options "DENY" always;
    proxy_pass http://portal;
}

If same-origin framing is a documented requirement, use frame-ancestors 'self' and X-Frame-Options: SAMEORIGIN. If specific partner origins are required, list their exact HTTPS origins in frame-ancestors; X-Frame-Options cannot express a reliable multi-origin allowlist.

How to fix it#

1. Set CSP frame-ancestors. Use 'none' for pages that never need framing, 'self' for same-origin framing, or an exact allowlist of trusted origins.

2. Add X-Frame-Options for older clients. Use DENY or SAMEORIGIN. Do not rely on the obsolete ALLOW-FROM directive.

3. Apply the policy to every relevant response. Include normal pages, errors, authentication routes, sensitive workflows, and responses served through a CDN or alternate hostname.

4. Require confirmation for high-risk actions. Reauthentication, recent MFA, and clear transaction details reduce impact even when framing controls regress.

5. Use CSRF defenses. SameSite cookies and CSRF tokens address unwanted requests, while frame controls address visual deception. Deploy both according to the workflow.

6. Avoid JavaScript-only frame busting. It is a fallback for unusual legacy cases, not a substitute for response headers.

7. Isolate intentionally embeddable content. Host widgets on a separate origin with narrow capabilities and no ambient access to the main application's session.

8. Design resilient interfaces. Avoid placing destructive or security-sensitive actions in predictable one-click locations without review or confirmation.

How to test for it#

  • Create a controlled test page on a separate origin that embeds the target page in an iframe.
  • Verify the browser blocks framing and reports the expected CSP or X-Frame-Options decision.
  • Test normal pages, login, account settings, administrator functions, errors, and alternate hostnames.
  • If framing is allowed for specific partners, verify an approved origin works and a similar but unapproved origin fails.
  • Confirm proxies, CDNs, and application middleware do not remove or duplicate headers inconsistently.
  • Review frame-ancestors for broad schemes, wildcards, or origins that themselves permit untrusted content.
  • Test sensitive actions for fresh confirmation and CSRF protection even when framing is blocked.
  • Add automated response tests and a browser-based framing test to prevent deployment regressions.

References#

Permalinklibrary.infinity8labs.com/clickjacking/JSON
Found this in Breachvane? Your finding links here for background. Evidence, affected assets and retest status are in your Breachvane ↗ (opens in a new tab) workspace. Need help fixing it? Talk to us.