Clickjacking

Clickjacking tricks the victim into clicking something other than what they think. The attacker loads the legitimate site inside a transparent <iframe>, places it on top of their own decoy content and lines up a sensitive button (delete account, approve a payment, change a permission) right under the cursor. The victim believes they click the decoy, but the click lands on the real site, where they are already authenticated.

The attacker's page is as simple as this:

<style>
  iframe { position:absolute; top:0; left:0; width:100%; height:100%; opacity:0.0; z-index:2; }
  .lure  { position:absolute; top:420px; left:60px; z-index:1; }
</style>
<div class="lure">Click to win a prize</div>
<iframe src="https://victim.tld/account/delete"></iframe>

opacity:0 makes the iframe invisible and the z-index keeps it above the decoy, so the click "passes through" onto the real button. Variants: drag-and-drop to steal data across frames, and cursorjacking (offsetting the visible cursor from the real one). Because it relies on an action performed with an already-logged-in session, it is a cousin of CSRF but driven by user interaction.

How to detect it. There is no malicious request to grep: the signal is defensive, the absence of anti-framing headers. A site that responds without X-Frame-Options or Content-Security-Policy: frame-ancestors on pages with sensitive actions is vulnerable by definition. On the browser side, CSP reports (report-uri) flag framing attempts from foreign origins.

Defence. Send X-Frame-Options: DENY (or SAMEORIGIN) and, better, Content-Security-Policy: frame-ancestors 'none' (or the trusted-origin list) on every page with state-changing actions; mark cookies SameSite=Lax/Strict so the framed action does not carry the session; and use confirmations that do not hinge on a single click. It combines with misconfigured CORS and session hijacking to chain impact.