Clickjacking Bug Bounty 2026 — Find UI Redressing Vulnerabilities and Chain to Account Takeover | Bug Bounty Day20

Day 19 covered CSRF — cross-site request forgery — where forged requests trigger actions without user awareness. Day 20’s clickjacking is a related but distinct attack vector: instead of forging the request, you hijack the legitimate user interaction itself. The victim genuinely clicks, but they click on something different from what they believe they’re clicking on. Together, CSRF and clickjacking form the complete picture of client-side action hijacking — two techniques that every bug bounty hunter must know cold.

How Clickjacking Actually Works at the Browser Level

Clickjacking — also called UI redressing — exploits the browser’s ability to embed external pages inside iframes. An attacker creates a malicious web page that contains the victim’s target application in a transparent iframe layered over a deceptive UI. The iframe is positioned so that a sensitive button on the real application — the “Delete Account” button, the “Confirm Transfer” button, the “Authorise App” button — is precisely aligned under something the victim would genuinely want to click on the attacker’s page.

The browser renders both the attacker’s page and the iframe simultaneously. From the victim’s perspective, they see only the attacker’s page — the transparent iframe makes the underlying application invisible. When they click what appears to be the attacker’s button, the click event actually passes through to the invisible application underneath. The victim has just performed an authenticated action on the real application without knowing it. Their session cookies, authenticated state, and all permissions are fully active because it’s their browser loading the real page — the application has no way to know the click came through an iframe overlay.

The browser-level protection against this attack comes from HTTP response headers. When a server includes X-Frame-Options: DENY in its response, the browser refuses to render that page inside any iframe. X-Frame-Options: SAMEORIGIN allows same-origin frames only. The modern replacement is the Content Security Policy frame-ancestors directive — frame-ancestors 'none' blocks all framing, frame-ancestors 'self' allows same-origin. When both protections are absent, the page can be framed by any domain, and the entire clickjacking attack surface opens up.

Detection — Finding Missing Framing Protection with Burp Suite

Detecting clickjacking vulnerabilities is straightforward once you understand what you’re looking for in HTTP response headers. The challenge isn’t the detection itself — it’s doing it efficiently across large applications with hundreds of endpoints and knowing which responses are worth checking in detail. My workflow combines Burp Suite’s passive scanner (which flags missing X-Frame-Options automatically) with manual header review for high-value sensitive action endpoints that I identify by browsing the application.

When Burp Suite’s spider or manual browsing captures responses, the passive scanner runs automatically and adds “Missing X-Frame-Options header” issues to the Issues tab for every response missing the header. This gives you a map of the entire frameable surface of the application. Your next step is triage — not every missing header represents a viable bug bounty finding. You need to cross-reference the list of frameable URLs with the application’s sensitive action inventory to find the intersection where real impact exists.

One important nuance to understand: some pages set X-Frame-Options or CSP frame-ancestors on the main document response but not on sub-resources or API responses that populate the page. For clickjacking purposes, what matters is the header on the page the victim would need to be viewing — the page that contains the sensitive action button. Always check the specific response for the sensitive action page, not just the homepage or login page headers.

Which Pages Are Worth Framing — Impact Assessment

This is where most beginners go wrong with clickjacking. They find missing X-Frame-Options on a login page or a homepage, build a PoC, submit it, and get back a rejection: “Informational — no sensitive action affected.” Triagers have seen thousands of these submissions. Missing framing headers on a page with no sensitive action is a best practice violation, not a security vulnerability. To get paid, you need to find the intersection of two conditions: the page is frameable, and the page contains a sensitive action that causes real harm if triggered without the victim’s intent.

The hierarchy of valuable clickjacking targets starts with the most impactful: account deletion with no confirmation step, one-click financial transfers or purchases, OAuth authorisation endpoints where one click grants an attacker’s app access to the victim’s account, admin panel actions like user privilege escalation or account deactivation, and password change pages on applications that don’t require the current password. Below these sit medium-value targets: profile data modification, subscription changes, privacy setting toggles, and connected application authorisations. The bottom tier — login pages, public content, search functionality — rarely produces viable findings.

Building a Clickjacking PoC — The HTML Iframe Method

A proof-of-concept for clickjacking demonstrates that a victim can be made to perform a sensitive action without intending to. The PoC must include a realistic decoy that a victim would actually click — not just a blank page with a transparent iframe. Triagers need to be able to run the PoC and see the attack work in their browser. A PoC that requires expert knowledge to set up or that doesn’t visually demonstrate the overlap will slow down triage and may lead to a lower severity rating.

The HTML structure is simple: an outer div containing two layers. The bottom layer is the target application’s sensitive page in an iframe styled with opacity: 0.00001 (functionally transparent but technically present in the DOM — some browsers reject opacity: 0). The top layer is your decoy, positioned absolutely over the iframe at precisely the coordinates of the target’s sensitive button. The iframe is sized to match the target page’s layout, and the decoy button is positioned using CSS absolute positioning to align exactly with the action button underneath.

When calibrating the PoC, use opacity: 0.5 temporarily so you can see both layers simultaneously. Adjust the top and left CSS values of the decoy button until it appears to overlap the target’s real action button. Once perfectly aligned, reduce the opacity to 0.00001 and test the click. If the target action fires when you click the decoy — and the iframe was genuinely invisible — your PoC is ready. Document the exact pixel values and include them in your report so triagers can reproduce without guessing.

Burp Clickbandit — Automated PoC Generation

Manually calibrating iframe pixel positions is time-consuming when you have many targets to test. Burp Suite’s Clickbandit tool eliminates this problem entirely. Clickbandit records your interactions with the real target page, identifies the precise positions and sizes of the buttons you click, and generates a polished PoC HTML file automatically. The output is presentation-ready — the kind of PoC that impresses triagers because it requires no setup and works immediately when opened in a browser.

Clickbandit runs inside Burp Suite’s embedded Chromium browser. You navigate to the target page, launch Clickbandit, click the buttons you want to demonstrate being clickjacked, then export the PoC. The exported file contains all the necessary pixel calculations already done and typically includes a slider that lets the triage reviewer reveal the hidden iframe underneath the decoy layer — a powerful demonstration that makes the attack mechanism visually obvious.

Chaining Clickjacking with CSRF for Critical Severity

Individual clickjacking vulnerabilities require user interaction — the victim must be on the attacker’s page and click the decoy element. This “requires user interaction” limitation is why standalone clickjacking typically lands at Medium severity. Chaining clickjacking with CSRF removes this limitation on certain applications and pushes the finding into High or Critical territory.

The chain works when the sensitive action on the frameable page uses either no CSRF token at all, or a CSRF token that is predictable, reused, or can be extracted through a secondary vulnerability. In this scenario, the attacker’s page loads the iframe transparently, uses JavaScript to submit the form automatically as soon as the page loads, and the action fires before the victim has even read the page — let alone clicked anything. Account deletion, permission grants, and financial transfers using this chain are Critical findings on virtually every major bug bounty programme.

Even without a full CSRF chain, clickjacking combined with a drag-and-drop technique can steal clipboard content or force OAuth authorisation in a single interaction. The PortSwigger Web Security Academy has an excellent series of chained clickjacking labs covering multi-step attacks, drag-and-drop clipboard theft, and frame-busting script bypass that are worth completing in full as part of this day’s study.

Writing Clickjacking Bug Bounty Reports That Get Paid

The quality of your report determines whether a valid finding gets paid or rejected. I’ve reviewed hundreds of bug bounty reports in my career and the most common reason a valid clickjacking finding gets downgraded or rejected isn’t the vulnerability itself — it’s that the hunter didn’t demonstrate realistic impact. “The page is missing X-Frame-Options” tells a triager you found a header. A full report with a working PoC, a documented victim scenario, and a calculated business impact tells them you found an attack. These two framings produce completely different outcomes.