Frontend Beauty
ESC

Type to search the knowledge base.

Clickjacking and X-Frame-Options

Stop UI redress attacks with frame-ancestors CSP and X-Frame-Options; know when embedding is intentional.

intermediate3 min read
  • security
  • clickjacking
  • x-frame-options
  • csp
  • iframes

Clickjacking (UI redress) stacks a transparent iframe of your site over a decoy UI so users click “Play” while actually clicking “Delete account” on your origin. Defense is don’t allow untrusted parents to embed you — via CSP frame-ancestors and legacy X-Frame-Options.

Docs: MDN X-Frame-Options, CSP frame-ancestors, OWASP Clickjacking.

Attack sketch

<!-- attacker.com -->
<iframe src="https://bank.example/transfer" style="opacity:0.01; position:absolute;"></iframe>
<button style="position:absolute;">Win a prize</button>

User thinks they click the prize; the click hits the iframe.

Modern defense: CSP

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

Or allow specific parents:

Content-Security-Policy: frame-ancestors 'self' https://partner.example

frame-ancestors is the preferred control (not in <meta>; use headers).

Legacy: X-Frame-Options

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

No allowlist of multiple origins in the original header (browser quirks exist). Prefer CSP; send both during migration if needed.

When embedding is required

Admin tools in a portal, marketing CMS, payment flows:

  1. Allowlist exact parent origins in frame-ancestors.
  2. Consider cookie SameSite and partitioned cookies for third-party iframe auth pain.
  3. Sensitive actions may need re-auth even inside frames.

Framebusting JS is not enough

// fragile legacy
if (top !== self) top.location = self.location;

Attackers use sandboxing / XSS filters / double frames. Headers are the real control.

Reviewer prompts

  • What is the asset (session, PII, money movement)?
  • What is the attacker capability (web, XSS, network, dependency)?
  • Which control fails closed if misconfigured?
  • Is the server still enforcing authz?
  • Any new third party, iframe, or URL sink?

Residual risk note

Browser controls reduce likelihood and impact; they do not eliminate bugs. Prefer defense in depth: safe defaults in code, strict headers, and monitoring (CSP reports, auth anomaly alerts). When product pressure weakens a control, write down the accepted risk and a revisit date.

Exception process

If a partner must embed a read-only status page, host that page on a dedicated path with a tighter CSP, minimal cookies (SameSite, possibly partitioned), and no privileged actions. Do not relax frame-ancestors globally for one partner widget. Prefer partner-side screenshots or public APIs over embedding authenticated app chrome.

When you embed third parties, sandbox and permissions — Sandboxing iframes, Permissions-Policy.

Interview out-loud

“Clickjacking tricks users into clicking hidden UI in a framed victim site. I set CSP frame-ancestors none or an allowlist, and X-Frame-Options as legacy backup. Framebusting scripts are not sufficient.”

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.

Further reading

Related guides