Imagine a visitor arrives on what appears to be a simple webpage — a competition entry, a news article, a special offer. They click a button. But unbeknownst to them, your website was loaded invisibly behind the page they were looking at, and what they actually clicked was a button on your site: “Confirm Payment”, “Transfer Funds”, or “Grant Access”.

That is clickjacking — and if your website does not send the right security header, it can be done to your site right now.

What Is Clickjacking?

Clickjacking — also called a UI redress attack — works by loading one website inside another using an HTML element called an iframe. The attacker’s page positions your website behind their own visible content, adjusting transparency and positioning so your site’s interactive elements align exactly with harmless-looking elements on their page.

When a visitor clicks what they think is a button on the attacker’s site, they are actually clicking a button on yours — without realising it.

What Can an Attacker Do?

The usefulness of clickjacking depends on what your website allows visitors to do:

Online banking and payments. A victim is tricked into clicking “Confirm Transfer” on their online banking session without realising they are interacting with their bank at all. Early versions of this attack targeted PayPal and banking sites before the protections became widespread.

Social media actions. Victims are tricked into clicking “Like”, “Share”, or “Follow” on social platforms. This was used extensively on Facebook between 2010 and 2013 in so-called “likejacking” campaigns that spread virally.

Authorising access. In OAuth flows — where you click “Allow this app to access your account” — clickjacking can trick users into granting third-party access without consent.

Account actions. Clicking “Delete Account”, “Change Email”, or “Enable Admin Access” without realising it.

If your website has a logged-in area, an e-commerce function, or any form that performs an action, clickjacking is a relevant threat.

A Real-World Example

In 2008, security researchers Robert Hansen and Jeremiah Grossman publicly demonstrated clickjacking against Adobe Flash settings panels — an attack that could silently enable a victim’s webcam and microphone. Adobe had to patch Flash as a direct result.

Facebook suffered multiple clickjacking-based attacks between 2010 and 2013, where users were tricked into liking pages or sharing content without their knowledge. More recently, clickjacking techniques have been combined with other attacks in sophisticated phishing campaigns targeting financial institutions.

The Fix: X-Frame-Options and Content-Security-Policy

There are two HTTP headers that prevent your website from being loaded inside an iframe:

X-Frame-Options is the older, simpler option:

  • X-Frame-Options: DENY — your page can never be framed.
  • X-Frame-Options: SAMEORIGIN — your page can only be framed by pages on the same domain.

Content-Security-Policy with frame-ancestors is the modern, more flexible option:

  • Content-Security-Policy: frame-ancestors 'none' — equivalent to DENY.
  • Content-Security-Policy: frame-ancestors 'self' — equivalent to SAMEORIGIN.

Most security guidance recommends setting both for maximum browser compatibility — older browsers may only understand X-Frame-Options.

How to Add These Headers

In Apache (via .htaccess):

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self'"

In Nginx:

add_header X-Frame-Options "SAMEORIGIN";
add_header Content-Security-Policy "frame-ancestors 'self'";

In Cloudflare: Add these via Transform Rules without touching your server.

In WordPress: Security plugins like Wordfence and Solid Security add these headers automatically through their settings panels.

DENY vs SAMEORIGIN: If you genuinely need your pages to be embeddable — for example, you have a booking widget that other sites legitimately embed — DENY would break that. If you have no legitimate use for framing, DENY is the safer choice.

What to Do Next

  • Check whether your site already sends X-Frame-Options. Use your browser’s developer tools (Network tab, inspect the response headers) or a free header checker tool.
  • Add both X-Frame-Options and Content-Security-Policy: frame-ancestors through your web server configuration, CDN, or security plugin.
  • Choose DENY unless you have a specific need for framing. This is the strongest protection.
  • Test after adding to confirm nothing breaks — particularly any embedded widgets or third-party integrations.

The effort to add these headers is minimal — a few lines of configuration — and it completely neutralises an attack vector that criminals actively exploit. The X-Frame-Options header is consistently listed by the NCSC, OWASP, and web security frameworks worldwide as a header every website should have.

W3IT’s free security check checks whether your site sends the X-Frame-Options and Content-Security-Policy headers. It is free, instant, and will tell you exactly what you have and what you are missing.