What Is Clickjacking?

Clickjacking is a UI redress attack that tricks people into clicking something different from what they think they are clicking, usually by hiding a real button under a transparent layer or a convincing overlay. The victim believes they are pressing a harmless control, but the click is rerouted to approve a payment, change a setting, or grant account access. Because the person performs the action themselves, clickjacking slips past passwords and input validation. This guide explains how the attack works, the main types you will meet, and the exact controls that shut it down. The most useful fix is not where most teams look first.

Key Takeaways

• Clickjacking hijacks legitimate clicks with invisible iframes or overlays, so login security alone cannot stop it.
• The attack abuses the browser’s normal framing behavior, which means the defense belongs in HTTP response headers, not application code.
• The two controls that matter most are the Content-Security-Policy frame-ancestors directive and the X-Frame-Options header.
• Common variants include likejacking, cursorjacking, and nested clickjacking, each abusing a different part of the interface.
• JavaScript frame-busting scripts are easy to bypass and should never be your only line of defense.
• A web application firewall can apply anti-framing headers to every response across your entire domain, closing gaps that individual developers might miss.
• Testing takes minutes: try to load your sensitive page inside an iframe and see if it renders.

What Is Clickjacking and Why It Fools Users

Clickjacking is an attack in which a malicious page overlays or frames a legitimate site, so that a user’s click lands on a hidden element rather than the one they see. The technique is also called UI redress, because it re-dresses a trusted interface with a deceptive skin.

Security researchers Robert Hansen and Jeremiah Grossman named the technique in 2008, after showing how a transparent Adobe Flash settings dialog could be framed to change a webcam permission with a single click. The core idea has not changed since. An attacker puts something the user wants on top, and something the attacker wants underneath, then lines them up pixel for pixel.

What makes clickjacking different from most web attacks is that nothing is technically broken. The browser loads the frame, renders the layers, and registers the click exactly as designed. There is no malformed input to reject and no injected script to sanitize.

Think of it like a street performer’s shell game. You watch the cup you are told to watch, you point with full confidence, and the trick works precisely because your attention was guided to the wrong place.

That is the part most teams miss. They harden authentication, add rate limits, and validate every form field, then leave the framing surface wide open. A layer 4 DDoS protection service stops traffic floods, but clickjacking sends a single, quiet, authenticated click that appears completely normal in your logs.

In 2010 and 2011, likejacking campaigns spread across social platforms by hiding a Like button under fake video play buttons, collecting millions of unwanted endorsements. A few years later, researchers showed that the same overlay trick could silently enable browser plugins or bypass permission screens in real applications.

Knowing the definition is one thing. Watching the click actually get stolen, step by step, makes the risk impossible to ignore.

How a Clickjacking Attack Works

A clickjacking attack works by loading the target site inside an invisible frame, placing a sensitive button beneath a harmless-looking decoy, and tricking the victim into clicking the spot where the two overlap.

The attacker controls the outer page, so they control opacity, position, and stacking order. They set the framed target to near-zero opacity, float it above their own decoy content, and align the hidden button with something irresistible, such as a game, a prize, or a play button.

A transparent iframe places the real action directly under the decoy the user actually sees.

1. The attacker builds a page and loads your site in a hidden iframe set to full transparency.
2. They place a decoy element, such as a “Claim now” button, directly under the framed sensitive control.
3. They drive traffic to the page with clickbait, a fake giveaway, or a malicious ad.
4. The victim clicks the decoy, but the click reaches the invisible button beneath it.
5. The action runs within the victim’s logged-in session, so it appears fully authorized.

You might be thinking that the real site loading in the background would give the game away. It does not. With opacity set to 0, the framed page is invisible yet fully clickable, so the victim sees only the decoy.

One pattern security teams see often involves home router admin panels. A framed “Save settings” button appears beneath a fake CAPTCHA, and a single click quietly changes the router’s DNS to an attacker-controlled server.

Another involves one-click account actions. A social app that lets you delete your account or revoke a session with a single button becomes a prime target, since the attacker only needs one hijacked click to cause damage.

The mechanics are always similar, but the disguise changes. Those disguises are what separate one type of clickjacking from another.

Types of Clickjacking Attacks

Clickjacking comes in several forms, and they differ by which part of the interface they abuse: the whole page, a social widget, the cursor, or nested frames. Knowing the type helps you understand the risk, though most share a single prevention path.

Here is the counter-intuitive part. The flashiest variants, like cursorjacking, get the research headlines, but plain overlay clickjacking on a single-click action causes the most real damage because it is the easiest to pull off at scale.

A payments team we reviewed found a marketing microsite that framed their one-click “confirm subscription” endpoint. No cursor tricks and no nested frames, just a transparent overlay and a fake “Play video” button doing all the work.

If a single policy can shut down most of these at once, the obvious next question is how you find out whether your site is exposed in the first place.

How to Detect and Test for Clickjacking Vulnerabilities

You can detect clickjacking exposure in minutes by checking whether your pages send anti-framing headers and whether they render inside an iframe you control.

Detection has two halves. First, confirm that the response headers that block framing are actually present. Second, prove it by trying to frame the page yourself. A header can be set on one route and missing on another, so testing the real page matters.

1. Run curl -I against the URL and look for content-security-policy and x-frame-options in the response.
2. Create a blank HTML file with a single iframe pointing at your page, then open it in a browser.
3. If the page renders inside the frame, framing is allowed, and the page is exposed.
4. Repeat for sensitive routes specifically: login, checkout, account settings, and any one-click action.
5. Scan the entire site with a tool like OWASP ZAP or a header checker to catch routes you would not test manually.

Yes, an online header scanner will flag a missing X-Frame-Options header on your homepage. But a green result on the homepage says nothing about your checkout subdomain or your legacy admin panel, which are exactly the routes attackers care about.

An e-commerce team we audited set frame protection on their main domain and assumed they were covered. Their checkout ran on a separate subdomain that shipped no framing headers at all, so the most sensitive page on the site was the only one still framable.

A SaaS platform passed every automated header scan, yet stayed exposed on three internal tool routes that predated their security policy and were never migrated.

Once you know which routes are exposed, fixing them is mostly a matter of sending the right two headers. Here is exactly what to send.

How to Prevent Clickjacking: Security Headers and Techniques

To prevent clickjacking, tell the browser who is allowed to frame your pages using the Content-Security-Policy frame-ancestors directive, and add the X-Frame-Options header as a fallback for older clients.

The right headers define the framing rule; enforcing them everywhere is what makes the rule hold.

Every reliable clickjacking defense comes down to controlling framing. frame-ancestors is the modern, flexible control. It lets you allow your own origin, a list of trusted partners, or nobody at all. X-Frame-Options is the older header that does roughly the same job with less nuance, and it still helps on legacy browsers.

These prevention techniques stack into a short checklist you can apply across the whole site:

• Set frame-ancestors on every route by default, then loosen it only where embedding is genuinely needed.
• Keep X-Frame-Options as a companion header for older browser coverage.
• Add SameSite=Lax or Strict to session cookies so a framed cross-site request carries no credentials.
• Require an explicit confirmation step for destructive or financial actions.
• Do not rely on JavaScript frame-busting scripts as your main iframe security control.

You might assume X-Frame-Options is deprecated and safe to drop. In practice, frame-ancestors supersedes it and is the controlling one, but keeping the older header costs nothing and covers the rare outdated client, so send both.

The classic mistake is trusting frame-busting JavaScript, the little script that tries to break your page out of a frame. Attackers neutralize it with the sandbox attribute or nested frames, and it fails completely when the user has JavaScript disabled. Headers work at the browser level before your script ever runs, which is why they win.

Where you enforce these headers matters as much as which ones you pick. Serving them from a secure CDN means that every edge location includes them in every response, even for cached pages. With edge computing, you can inject or rewrite framing headers close to the user without touching each application. A traditional network firewall filters traffic by ports and IP addresses, so it never sees the framing behavior that clickjacking relies on.

Setting headers correctly on every route sounds simple until you have dozens of services and teams. That is the gap a web application firewall was built to close.

Preventing Clickjacking Attacks with WAF Protection

A web application firewall prevents clickjacking by enforcing anti-framing headers on every response across your entire domain and blocking requests that attempt to abuse framing, all without changing application code.

The hardest part of clickjacking defense is not knowing the right header. It is ensuring that the header is present on every route, every subdomain, and every legacy endpoint, indefinitely. Individual services drift, new microservices ship without the policy, and one missed route is all an attacker needs.

This is where an advanced web application firewall earns its place. Instead of trusting each team to remember frame-ancestors, the firewall injects and enforces the header centrally at the edge for responses that lack it. A cloud-based advanced web application firewall saas applies the same policy everywhere at once, so a newly deployed service inherits WAF clickjacking protection the moment it goes live.

1. Define a baseline framing policy: frame-ancestors ‘self’ plus X-Frame-Options as a fallback.
2. Configure the WAF to add these headers to any response that does not already set them.
3. Allowlist the specific routes that legitimately need to be embedded.
4. Enable logging so you can see which routes were missing the header and would have been exposed.
5. Review the allowlist on a schedule, so old embedding exceptions do not linger.

A SaaS company with more than 30 services came to us after a pen test framed one forgotten internal tool. Rather than patch 30 codebases, they set one framing policy at the firewall and closed every route in an afternoon.

A media site kept clickjacking protection on its article pages but not its account and billing flows. Enforcing the header at the edge covered both without a single code deploy.

You might expect a WAF to be overkill just for headers. But the value is not the header itself; it is the guarantee that the header is never missing, on any route, no matter who ships the next service.

Clickjacking is quiet, cheap for attackers, and easy to overlook. The good news is that shutting it down is equally cheap, once you put the fix in the right place.

Final Thought on clickjacking

Clickjacking succeeds because the victim’s click is real, which is why authentication, input validation, and traffic filtering all miss it. The attack lives at the framing layer, so the defense has to live there too. Tell the browser who may frame your pages with frame-ancestors, keep X-Frame-Options as a fallback, and harden session cookies with SameSite.

The principle to remember is consistency. A framing header that protects nine out of ten routes still leaves the tenth exposed, and attackers need only the one. Set the policy as your default, allow embedding only where you truly need it, and enforce it in one place so no future service can quietly opt out. Do that, and clickjacking stops being a risk you have to think about.

Frequently Asked Questions About clickjacking