Clickjacking

Core idea

A browser will display one site inside a frame on another site unless somebody says not to. Clickjacking uses that. The victim sees what looks like the attacker’s page. A transparent frame of a site they are logged into sits on top, aligned so a click hits a real button: delete, transfer, approve, change a setting. The request itself may be a normal authenticated request. The lie is in the pixels.

This is not CSRF. CSRF forges a request the victim never saw. Clickjacking shows the real site and lies about what the click means. Defenses differ. A CSRF token does not stop a click on the real button. A framing policy does.

What to look for

• State-changing pages that can be framed
• Missing frame-ancestors in CSP, and missing X-Frame-Options on older stacks
• A framing policy on the login page and not on the settings page, or the reverse
• Defenses implemented only in script (“if we are framed, hide”), which the framing page can often interfere with. A browser-enforced header is the dependable control
• Actions that should also demand a fresh confirmation the framed context cannot silently satisfy

In the lab / in Burp

In Repeater, request the sensitive page and read the framing headers. Write down whether the browser is told to refuse framing, and by which header. If both CSP and X-Frame-Options are present, note which one modern browsers will prefer, and whether they agree.

The Academy lab may ask you to observe that a page can be framed when the header is absent. You can confirm the header behavior from the response itself. Do not publish a framing page, and do not frame a real application you are not allowed to test. A lab that wants the browser demo will host it.

Defensive controls

Send frame-ancestors with the origins that genuinely need to embed the page, often none. Keep X-Frame-Options where you still support clients that need it, with the same intent. Apply the header on every response that renders a sensitive action, not only on the home page. For high-impact buttons, require a confirmation that is hard to satisfy inside a hostile frame.

Common pitfalls

Thinking a CSRF token solved framing. Applying the header only to HTML documents and forgetting a sensitive route. Using a JavaScript frame-buster as the only defense. Confusing clickjacking with “UI redress” trivia and missing the header check, which is the whole exam point.

From the learning path

The February 2026 learning-path notes add cases this page should keep next to the header check.

A single click is the simple case. Some actions need two: put an item in a basket, then confirm the order. Each step is its own framed control, lined up with its own decoy. Both clicks are still real clicks on the real site, in the victim’s real session. A CSRF token does not see the lie, because the session is genuine and the requests stay on the target origin.

Some forms are already filled when the page loads, because the values rode in on the URL. The framed page can show the attacker’s values. The only thing left for the victim is the submit control.

X-Frame-Options: deny and CSP frame-ancestors 'none' ask for the same thing. sameorigin and frame-ancestors 'self' ask for the same thing. The older allow-from form names one site, and browsers do not implement it consistently, so a named allow list belongs in frame-ancestors.

A frame-busting script tries to notice that it is not the top window, force frames to be visible, or warn the person. It runs only if JavaScript runs. The page that created the frame can limit what the framed page is allowed to do, so the script is not a control you count on.

Burp includes Clickbandit for the Academy exercise. It watches clicks in the lab and builds an overlay there. Record the framing headers in these notes. Leave the overlay in the lab.

Clickjacking can also carry a second client-side bug. The framed address is one that already does something harmful in the victim’s session when the click lands. The framing policy still has to be present on that page. The second bug stays in its own note.