Clickjacking · Click hijacking
A click on a legitimate button. A fraudulent action confirmed.
Clickjacking exploits a page that looks safe. An invisible iframe hijacks a click into a malicious action, with no warning and no visible proof.
- Invisible iframe
- Hijacked action
- OWASP A05
Step-by-step simulation
Follow the attack step by step
Visible page
Download the report
Subscription to confirm
4,99 €/mois
An internal page that looks safe
The user sees a legitimate button on their intranet. They're not suspicious.
An interface people trust
HR dashboards, payment forms, resource access: these pages are visible and familiar. One invisible overlay is enough to trick a click.
Key figures
One click, no warning
- OWASP Top 10 · 2021
A05
Security Misconfiguration- click required
0
to trigger the attack- visible warning
0
for the user- to hijack the transaction
< 0s
via a malicious iframe
Protection
How to protect yourself
Clickjacking is blocked server-side, by forbidding third-party sites from embedding your pages.
CSP frame-ancestors
The frame-ancestors 'self' (or 'none') directive stops any third-party site from showing your pages in an iframe.
X-Frame-Options
DENY or SAMEORIGIN as a complement, to cover older browsers.
SameSite cookies
With SameSite=Lax or Strict, the session isn't sent from a third-party iframe.
Confirm sensitive actions
Payment, deletion, permission changes: require explicit confirmation (password, MFA).
Technical demo
Clickjacking simulator
This simulation shows how a legitimate action can be hijacked by an invisible iframe, then blocked thanks to browser protections.
Interactive demonstration
Clickjacking — click hijacking
A transparent iframe overlays a legitimate button. The user's click activates a hidden action — here a paid subscription at €4.99/month — without them knowing.
How hackers steal your credentials — 5 lesser-known techniques in 2026
Phishing now accounts for only half of account theft. Methods are evolving: infostealers, credential stuffing, adversary-in-the-middle…
Attackers now use ready-made kits available for under €20 on specialized forums. These tools automatically generate login pages identical to Microsoft's, Google's, or your bank's…
This article is reserved for Premium subscribers
Free access for 7 days, no commitment
Attack architecture
Legitimate page
banque-pro.fr
Transparent iframe
opacity: 0 — z-index: 9
User click
Target: the iframe, not the page
How to test it
- Click "Read the full article →"
- Enable "Reveal the iframe" to see the overlaid layer
- Enable "Protection ON" to see how X-Frame-Options blocks the attack
Documented real-world examples
- ·Premium subscriptions activated via "Close ad" buttons (a documented practice)
- ·Clicking "I agree" on invisible overlaid terms of service
- ·Camera/mic activation via fake video play buttons
- ·Bank transfers via corporate portals (2016 SWIFT fraud: $81M)
Invisible by design
The malicious iframe is positioned with opacity: 0 and a high z-index. The user only sees the page underneath, never the real target of their click.
Instant action
A single click is enough. The attacker doesn't need your password — your authenticated session confirms the action on your behalf. No further confirmation.
Countermeasures
X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none' prevent any iframe embedding. On the UX side: 2FA confirmation for sensitive actions.
FAQ
Frequently asked questions
What is clickjacking?
Clickjacking (click hijacking) overlays a transparent malicious page on top of a legitimate site via an invisible iframe. When the user clicks what they believe is a button on the legitimate site, they actually click the invisible layer and trigger an unwanted action (like, purchase, OAuth authorization, bank transfer).
How do you protect against clickjacking?
Protection against clickjacking: configure the HTTP header X-Frame-Options: DENY (forbids all framing) or SAMEORIGIN (allows only the same domain), or use Content-Security-Policy: frame-ancestors 'none'. These headers prevent the site from being loaded in an iframe by third-party domains.
Which HTTP header protects against clickjacking?
Two headers protect against clickjacking: X-Frame-Options (DENY or SAMEORIGIN, universal support) and Content-Security-Policy with the frame-ancestors directive (more modern, more flexible). CSP is preferred because it allows whitelisting specific domains and officially replaces X-Frame-Options.
What are real-world examples of clickjacking attacks?
Famous examples: the 2009 Twitter attack (likejacking forcing retweets), 'cursorjacking' attacks hijacking the cursor, invisible iframes on game pages forcing purchases, and attacks against unprotected admin interfaces allowing security settings to be reset.
Train your teams with an expert
Tailored awareness workshops, attack simulations and training to anchor the right reflexes in your organization.