auditing-clickjacking-and-ui-redressing

Auditing clickjacking and UI redressing: the user clicks your button on the attacker's page

Clickjacking works because the browser will happily render your real, authenticated page inside a frame on someone else's site, and the user cannot tell. The attacker loads your page in a transparent or hidden iframe, positions it under decoy content, and lures the user into clicking what looks like the attacker's button, when the click actually lands on your page, taken with the user's own session. So any sensitive, state-changing action that a single click can trigger, changing a setting, confirming a purchase, granting an approval, connecting an account, is exposed if your page can be framed by another origin. The defense is to refuse framing by untrusted origins, with a Content-Security-Policy frame-ancestors directive (and the older X-Frame-Options as a fallback), and, for the highest-value actions, to not make them one-click blind: a confirmation the overlay cannot fake. Related redressing tricks, drag-and-drop and keystroke capture, exploit the same framing to steal input. The audit checks, for every sensitive page, whether it can be framed and whether its state-changing actions are reachable by a single hidden click. You audit this by trying to frame the real page from another origin and drive its actions.

When to use

• A web page performs authenticated, state-changing actions triggerable by a click (settings, purchase, approval, connect, delete).
• The page may lack a frame-ancestors CSP directive or X-Frame-Options, so another origin can frame it.
• A sensitive action may be one-click with no confirmation an overlay cannot hide.

Scope check

Audit clickjacking only on applications you own or are authorized to assess. Framing the real site to demonstrate the attack uses a real authenticated session, so use test accounts and your own attacker-page test harness and never trick a real user or act on an account that is not yours. If you can't name the authorization, stop.