Clickjacking: When Your Website Becomes an Invisible Weapon

Here's an unsettling idea: an attacker builds a page that says "Click here to win a free iPhone." A giant, tempting button. But floating invisibly on top of that button — loaded in a transparent frame — is your website, positioned so that the invisible "Delete my account" or "Transfer funds" or "Authorise this app" button sits exactly where the fake button appears.

Your user, logged into your site, clicks "win a free iPhone." What they actually click is your button. They just performed a real action on your site without ever knowing they were on it.

That's clickjacking, and it's both clever and completely preventable.

How the trick works

Clickjacking relies on a feature browsers have had forever: the ability to embed one page inside another using a frame (an <iframe>). Normally that's useful — embedding a video, a map, a payment widget.

The attack abuses it like this:

1. The attacker loads your real, functioning site inside an invisible frame on their malicious page.
2. They set that frame's opacity to zero, so it's completely see-through.
3. They design their visible page so that an enticing element (a button, a game, a "play" arrow) sits precisely over a sensitive control on your embedded site.
4. When the victim — who is logged into your site — clicks the bait, the click passes through to your hidden site and triggers a real action.

Because the victim is genuinely authenticated with you, the action succeeds. They "clicked it" themselves, after all. The consequences range from mildly annoying (following an account, liking a page) to serious (changing settings, authorising a connected app, confirming a transaction).

Why it's easy to miss

Clickjacking leaves no trace in your logs that looks wrong — the request came from a real, logged-in user who really did click. There's no injection, no malware, no broken code on your side. Your site works perfectly. It's just being used perfectly, by someone else, as a component in an attack.

That's what makes it a favourite for social-media manipulation, fake "like" and follow farming, and tricking users through OAuth authorisation flows.

The fix is almost embarrassingly simple

Clickjacking has a near-total defence that takes one line of configuration: tell browsers who is allowed to frame your site.

There are two headers for this:

• Content-Security-Policy: frame-ancestors — the modern, preferred way. Setting frame-ancestors 'none' means "no one may embed my pages in a frame," and frame-ancestors 'self' means "only my own site may." Any attacker's framing attempt is blocked by the browser.
• X-Frame-Options — the older header (DENY or SAMEORIGIN) that does the same job for older browsers. It's worth setting both for full coverage.

With these in place, when the attacker tries to load your site in their invisible frame, the browser simply refuses. The whole attack collapses. No frame, no clickjacking.

The only nuance: if you do legitimately need certain partners to embed your pages, you list those specific origins in frame-ancestors rather than blocking everyone. Explicit and stingy, same principle as CORS.

The bigger lesson

Clickjacking is a perfect example of a whole category of web security: problems you fix not by writing clever code, but by sending the right HTTP headers. Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options — these are cheap, powerful, and constantly forgotten, especially in projects that were vibe-coded or spun up fast. A framework won't add them for you unless you ask.

Where Safeey fits

This is squarely Safeey's home turf. Checking security headers is one of the very first things Safeey does on every scan — it tells you exactly whether your site can be framed by an attacker, whether your frame-ancestors/X-Frame-Options are set, and which of the other high-value headers are missing, along with the precise value to add. Fixing clickjacking is often a two-minute change once you know it's needed.

Scan your site with Safeey to see whether an attacker can frame it.