Questions › Networking/Security
What is clickjacking, and which HTTP security headers should a production app set? Explain what each one does.
Knowledge of framing-based attacks plus the practical security-header hardening checklist for a real app.
CLICKJACKING (UI redress) is an attack where a malicious page loads YOUR site in a transparent or disguised iframe and overlays it with its own deceptive UI, so the victim thinks they're clicking the attacker's page but their clicks actually land on your framed page — e.g. an invisible 'Delete account' or 'Approve payment' button positioned under a fake 'Win a prize' button. The defense is to control WHO CAN FRAME your pages. Two headers do this: X-Frame-Options (the older header: DENY = never framed, SAMEORIGIN = only your own origin may frame it) and the modern replacement, the CSP directive frame-ancestors (frame-ancestors 'none' or frame-ancestors 'self' https://trusted-partner.com), which is more flexible and takes precedence in modern browsers. Set one (frame-ancestors preferred) on any page that performs actions. That's the specific fix; a production app should also set the broader hardening headers: (1) Strict-Transport-Security (HSTS) — forces HTTPS for the domain for a max-age, blocking SSL-stripping/downgrade and protecting first-load with includeSubDomains and preload. (2) Content-Security-Policy — the XSS/injection net (nonce-based, as discussed), also carrying frame-ancestors. (3) X-Content-Type-Options: nosniff — stops the browser from MIME-sniffing a response into an executable type (prevents a text/plain or image being run as script). (4) Referrer-Policy (e.g. strict-origin-when-cross-origin or no-referrer) — limits how much of your URL leaks in the Referer header to other sites, protecting tokens/PII in URLs. (5) Permissions-Policy (formerly Feature-Policy) — disables powerful APIs you don't use (camera, geolocation, microphone) so injected/embedded content can't invoke them. (6) The Cross-Origin isolation trio — Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP), and Cross-Origin-Resource-Policy (CORP) — which isolate your browsing context (mitigating Spectre-style cross-origin leaks and enabling powerful features like SharedArrayBuffer). Also set Set-Cookie flags (HttpOnly/Secure/SameSite) which we covered. Operationally: don't hand-maintain these per-response — set them at the edge/framework layer, test with a header scanner, and roll CSP out in Report-Only first. The mental model: each header closes one class of attack (framing, downgrade, injection, MIME confusion, referrer leakage, API abuse, cross-origin leaks), and 'defense in depth' means shipping the whole set, not picking one.
Hardening a production app; preventing clickjacking; assembling a security-headers checklist.
Clickjacking: attacker iframes your page invisibly, overlays fake UI,
victim's clicks hit YOUR framed buttons. Fix = control framing.
Production security headers:
Content-Security-Policy: ...; frame-ancestors 'none' XSS net + anti-framing
X-Frame-Options: DENY legacy anti-framing
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload force HTTPS
X-Content-Type-Options: nosniff no MIME sniffing
Referrer-Policy: strict-origin-when-cross-origin limit URL leakage
Permissions-Policy: camera=(), geolocation=(), microphone=() disable unused APIs
Cross-Origin-Opener-Policy: same-origin isolate context (COOP)
Cross-Origin-Resource-Policy: same-origin (CORP; COEP pairs with it)
Set at edge/framework layer, scan to verify, roll CSP out Report-Only first.