Clickjacking

What Is Clickjacking?

Clickjacking (also called UI redress) is the attack where an attacker embeds a victim site in a low-opacity or fully transparent iframe on their own page, then overlays clickable elements at the screen coordinates of sensitive buttons on the embedded site. The victim sees the attacker's page (a giveaway offer, a quiz, anything click-driven) and clicks where the attacker tells them to, but the click is routed through the topmost element under the cursor, which is the invisible iframe. The click lands on a real Approve Payment button, a real Authorise Permission button, a real Delete Account button. The defence is to set a response header that tells the browser to refuse the embedding venue entirely: Content-Security-Policy: frame-ancestors 'none' (modern, supersedes X-Frame-Options) or X-Frame-Options: DENY (legacy fallback). This exercise puts you on both sides. As Bob, you build a free-coffee giveaway page that embeds Tideline Bank's payment-approval form in a transparent iframe and renders a fake 'Claim free coffee' button at the exact screen coordinates of the real Approve button. As Alice, on the receiving end of a fraud alert that a $2,500 payment was approved moments after the victim opened a promo page, you open the approval handler, see res.send with only Content-Type set, and apply the fix: a single res.setHeader call adding the frame-ancestors policy. The exercise closes with quiz questions on what clickjacking is, which header reliably blocks it, why browser-side enforcement is the right design, and what the default should be for an application that does not need to be embedded anywhere.

What You'll Learn in Clickjacking

• Recognize clickjacking as a UI-redress attack, the click is real and the user authorised it; the visual context they thought they were clicking in was a lie
• Apply <code>Content-Security-Policy: frame-ancestors 'none'</code> (or the legacy <code>X-Frame-Options: DENY</code>) on every state-changing response
• Understand that browser-side enforcement is intentional, the server cannot reliably detect 'this request is loading me inside an iframe' but the browser knows the embedding context for certain
• Pair the per-route header with a global anti-framing middleware so the next state-changing form ships with the protection by default
• For legitimate embedding (partner portal, internal dashboard), use <code>frame-ancestors 'self'</code> or an explicit allow-list of trusted origins, never blanket allow-all

Clickjacking — Training Steps

1. Bob cannot move the money himself

   Bob cannot reach into a stranger's bank account. But Tideline Bank lets any customer request a payment from another, and the money moves only after the account holder approves the request. His target today is a Tideline Bank customer, Alice. He starts on the bank's request page.

2. Stage the payment request

   Signed in to a mule account named Coastal Marketing LLC , Bob files a request to pull $2,500 from Alice's account. He enters her email and the amount.

3. Set the trap

   The request now sits in Alice's account, waiting for her to tap Approve . She never would, knowingly. So Bob builds a free-coffee giveaway and hides her own Approve button directly beneath the coffee button. Then he emails her the giveaway and waits for a single click.

4. A free-coffee email

   Off the clock, Alice gets a cheerful email: a free coffee, one click to claim. Nothing asks for a password. It looks completely harmless.

5. Claim the coffee

   Alice clicks the link to claim her free coffee.

6. One click

   The giveaway page opens: one friendly button offering a free coffee. Alice clicks it. Nothing she can see changes. The coffee page just sits there.

7. Money leaves the account

   Seconds later, a fraud alert lands. A $2,500 payment she never knowingly approved has left her account.

8. See what the click hit

   Alice pulls the giveaway page back up. As a security engineer, she wants to see what her click really landed on. She drags a reveal control to fade in anything layered over the coffee button.

9. Name the attack

   Before touching any code, be precise about what just happened.

10. Open the approval handler

    Alice switches from victim to engineer. The approval page is produced by the payment-request service. She opens the handler to find out why it can be loaded on a stranger's site at all.