A tools listicle is only useful if the author is honest about how much tool there actually is. Clickjacking is a thin tool space: the attack is more PoC craft than tool-driven, and most "clickjacking tools" are either small HTML PoC generators or generic header checkers that flag a missing X-Frame-Options or frame-ancestors. I will not pad the list with abandoned utilities to pretend otherwise.
If you want the underlying mechanics first, the clickjacking deep dive covers the variants. For the wider context, the web application security vulnerabilities taxonomy places clickjacking alongside CSRF, which it often chains with.
The decision matrix
| Tool | Purpose | Licence | Maintained | Best for | Interface |
|---|---|---|---|---|---|
| Custom HTML PoC + clickjacker.com | Build the attack page | n/a | n/a | The actual attack craft | HTML |
| OWASP ZAP | Passive header scanner | Apache 2.0 | Active | Free CI/CD scanning, header checks | GUI + CLI |
| securityheaders.com | Hosted header grader | Hosted (free) | Active | Fast triage from a URL | Web |
| Mozilla Observatory | Wider defensive header grader | MPL 2.0 | Active | Header audit with CSP context | Web + CLI |
| Burp Suite (Pro) Active Scanner | Scanner flags missing headers | Commercial | Active | Bundled into the manual workflow | GUI |
| Older PoC kits (clickjacking-tester, xcalibur-style) | Standalone PoC frame generators | Mixed | Stale | Historical interest | CLI |
| DoubleClickjacking PoC repos | The 2024+ double-click variant | MIT-ish | Lightly maintained | The new variant, not yet in most scanners | HTML |
A quick read of the table: there is no sqlmap for clickjacking. The attack page is a small HTML file you write yourself or generate from a template. The "tools" are everything around it: defensive header checks before you bother building a PoC, and PoC repos for the newer variants.
1. Clickjacking PoC generators (clickjacker.com and custom HTML)
Site: clickjacker.com
The actual attack is a few lines of HTML. This is the canonical craft.
A clickjacking PoC is a page that loads the target inside an <iframe>, positions a decoy element above it with a higher z-index, and uses CSS opacity to hide the frame while keeping the click sink active on the framed page. clickjacker.com automates the boilerplate: paste a target URL, get a working HTML page that frames it. It is a teaching tool more than an attack tool.
What I like:
- Fast sanity check before writing custom HTML. If clickjacker.com cannot frame the target, the headers are doing their job and there is nothing to chain.
- Useful for client demos when you want a one-screen proof that the missing header has a real exploit.
- The generated HTML is readable; copy it out and modify rather than re-typing the iframe scaffold.
What I do not like:
- The generated PoC is generic. Real engagements need pixel-aligned decoys (the "Like" button over a "Delete account" submit), and you will end up hand-editing CSS anyway.
- No support for the modern variants: nested-frame, drag-and-drop, double-clickjacking, cursor-spoofing.
- It is a hosted tool. For a real engagement I would not paste a client target URL into someone else's web app. Build the PoC locally.
When to use it. Once, to see the shape of the PoC. After that, copy a minimal template into your own repo and edit by hand.
A minimal local template is twenty lines of HTML:
<!doctype html>
<style>
iframe { position:absolute; top:0; left:0; width:100%; height:100%;
opacity:0.0001; z-index:2; }
button { position:absolute; top:200px; left:300px; z-index:1;
font-size:18px; padding:12px 24px; }
</style>
<button>Click to claim your prize</button>
<iframe src="https://target.example.com/account/delete"></iframe>This is the entire tool surface for traditional clickjacking. Everything below this section is about deciding whether the target is even vulnerable in the first place.
2. OWASP ZAP
Site: zaproxy.org
Free passive scanner. The cheapest way to flag clickjacking exposure across a whole site.
ZAP's passive scanner includes an X-Frame-Options Header Scanner rule (alert ID 10020) and complementary rules for Content-Security-Policy frame-ancestors. Walk the application with ZAP recording, and every response missing the header is flagged automatically. No active probing, no payload traffic; just the response inspection that any defender could do themselves.
What I like:
- Free, open source, runs in CI. The headless mode plus
-cmd -quickurlis enough for a baseline. - Catches the boring case (header missing on the whole site) cheaply, leaving manual time for the interesting case (header present but bypassed by a nested-frame path).
- The same scan run pulls dozens of other header findings, so the clickjacking check is essentially free.
What I do not like:
- Flags absence of the header, not exploitability. A page can be unframeable in practice (no clickable controls on a logged-in state) and still trip the alert.
- Does not test bypasses: domain-allowlist holes in
frame-ancestors,ALLOW-FROMquirks in old browsers, the double-clickjacking variant. - Spider coverage on heavy JavaScript apps is shallow; you may need to feed ZAP a recorded session.
When to use it. Every engagement, as the first pass. The findings it surfaces are real but boring; clear them, then move to manual exploration.
3. securityheaders.com
Site: securityheaders.com
Hosted single-URL grader. Fast triage when you do not want to spin up ZAP.
Scott Helme's hosted tool fetches a URL and grades the response headers A through F, calling out X-Frame-Options, Content-Security-Policy, Strict-Transport-Security, and the rest of the defensive set. It is the fastest way to answer "does this site even bother with frame-ancestors?" without installing anything.
What I like:
- Sub-second answer for a single URL. No setup.
- The grading is calibrated against modern defaults and weights recent recommendations (CSP
frame-ancestorsoverX-Frame-Optionswhen both are present). - Shareable URL with a result, which is useful in a client message.
What I do not like:
- Tests a single URL only. Most clickjacking issues live on inner pages (the account-settings page, the form submission endpoint) and the homepage may pass while the dangerous pages fail.
- Hosted, so it tests as Scott's IP sees the response. CDN rules that vary by geography or user-agent will give a misleading result.
- No login support, so any header that is set only after authentication is invisible.
When to use it. Triage at the start of an engagement. If the homepage is F, you already know there is work to do. If it is A, you still have to check the post-login pages manually.
4. Mozilla Observatory
Site: developer.mozilla.org/en-US/observatory
Mozilla's hosted header analyser. Wider analysis, including CSP frame-ancestors context.
Observatory grades a similar surface to securityheaders.com but with more depth on CSP, including specific scoring for frame-ancestors. It also runs a TLS check and a few cookie checks alongside, so a single submission produces a more rounded defensive picture.
What I like:
- The CSP breakdown is the most useful part. It will call out an allowlist that includes
*or a wildcard subdomain inframe-ancestors, which is a real exploit primitive. - Open source and runnable locally (the
http-observatoryCLI), so you can wire it into CI without depending on the hosted service. - The scoring rationale is shown inline, not hidden behind a grade.
What I do not like:
- Same single-URL, no-login limitation as securityheaders.com.
- Some checks are opinionated in ways you may disagree with on a per-site basis. Read the rationale and decide.
- The hosted UI redesign in 2024 moved things around; the CLI is stable.
When to use it. When you want a second opinion on a header configuration, or when CSP is in play and you need the rule-level breakdown.
5. Burp Suite (Active Scanner)
Site: portswigger.net/burp
Not a clickjacking-specific tool; the platform the manual workflow runs on.
Burp's Active Scanner (Pro only) flags missing X-Frame-Options and weak frame-ancestors as part of a normal scan, the same way ZAP does, with the advantage that it is already running in the engagement workflow. For manual exploration, Burp's Repeater is where you confirm a header is actually missing on a specific endpoint (versus the homepage) and where you observe whether a Set-Cookie comes back with SameSite=None (which makes a clickjacking chain into a CSRF much more viable).
What I like:
- Already in the workflow. No additional tool to launch.
- Repeater lets you confirm header presence on a per-endpoint basis, which is the actual exploit surface.
- Extensions like
ClickjackerandCSP Auditoradd depth.
What I do not like:
- Pro licence is around 500 USD per user per year. The Community Active Scanner is hobbled and will not flag these issues.
- The bundled scan flags absence, not exploitability. Same caveat as ZAP.
- No native test for double-clickjacking yet.
When to use it. Always in the background. If Burp is already proxying the engagement, you do not need a separate header scanner.
6. Older PoC kits (clickjacking-tester, xcalibur-style)
Honest framing: stale or abandoned. Skim, do not adopt.
There is a long tail of small standalone PoC frame generators on GitHub from the 2014-2018 era. Most are unmaintained, written against old jQuery, and produce HTML you would have to clean up to be presentable anyway. The category includes clickjacking-tester, the xcalibur-style scripted clickjacking PoC repos, and a few one-off scripts that wrap an iframe template in a CLI.
What I like:
- Educational. Reading two or three of these is a fast way to internalise the PoC structure.
- A couple have multi-target loop modes (try every URL in a list, write the PoC HTML to disk per URL) that are useful when bulk-checking a large scope.
What I do not like:
- Stale: most have not seen a commit in three to five years.
- The generated HTML is dated; many still use
frameborder="0"and other deprecated attributes that modern browsers ignore or warn about. - None of them test bypasses or the newer variants.
When to use it. Almost never. The 20-line HTML template in §1 is faster than installing any of them.
7. DoubleClickjacking PoC repos (post-Paulos Yibelo)
The 2024+ variant. Not yet covered by the mainstream scanners.
In December 2024 Paulos Yibelo published DoubleClickjacking, a variant that exploits the time between the first and second click of a double-click to swap the framed target underneath the user's cursor. The defence is harder than the traditional version: X-Frame-Options and frame-ancestors do not stop the swap, because the swap happens in a window the attacker controls. A 2026 engagement that ignores this is incomplete on modern targets.
What I like (about the available PoCs):
- Several public PoC repos on GitHub demonstrate the technique in a copy-paste-runnable form. Search "doubleclickjacking poc" on GitHub for current ones; the exact repos churn.
- The technique reuses the iframe-and-decoy mental model. If you can build a traditional PoC, you can build a double-click one within an hour.
What I do not like:
- No mainstream tool (ZAP, Burp, securityheaders.com, Observatory) covers detection yet.
- The defence requires application-level mitigations (disable critical actions on a window that arrived via
window.openand lost focus between clicks). Header checks alone will not catch it. - The PoC repos are lightly maintained and skew toward proof-of-concept code quality rather than engagement-grade.
When to use it. On every engagement that touches authentication flows, OAuth consent screens, account-deletion UIs, or anything that uses a popup for a confirmation. The traditional headers do not defend against this; verify manually.
What I do not recommend
Random hosted "clickjacking testers" with no provenance
There are dozens of small hosted tools that promise to "test your site for clickjacking" via a form input. Almost all of them just fetch the URL server-side and check for X-Frame-Options. You do not need a hosted tool for that; curl -I does the same job:
curl -sI https://target.example.com/ | grep -i -E 'x-frame-options|content-security-policy'If the response has neither header on a logged-in page, you have your answer. Hosted "testers" add nothing.
"Clickjacking attack frameworks" that bundle a PoC builder behind a paywall
Several commercial pentest tool suites advertise clickjacking modules. In practice they wrap an iframe template that you can write in twenty lines. There is no inner-platform effect worth paying for here.
Tools I dropped from this year's list
- clickjacking-tester (various GitHub forks). Unmaintained, dated HTML output. Skim once, then write your own template.
- xcalibur and the late-2010s standalone PoC builders. Same family. Educational only.
- Old "browser extension" clickjacking checkers that overlay a red border on framed pages. Replaced by browser dev-tools, which show frame ancestry natively.
Which tool should I use? (Decision tree)
A short flow for the common cases:
- Are you triaging a single URL fast?
- Yes. securityheaders.com or
curl -Ifor the headers. Twenty seconds total.
- Yes. securityheaders.com or
- Are you scanning a whole application?
- Yes. OWASP ZAP for free, or Burp Active Scanner if Pro is already in the workflow. Both flag missing headers automatically.
- Are the headers present but you want to confirm exploitability?
- Yes. Hand-write the 20-line HTML template against the specific endpoint. Hosted PoC generators are a starting point only.
- Is the target an OAuth consent screen, an account-deletion confirmation, or anything that opens a popup for an action?
- Yes. Test the double-clickjacking variant manually. Headers will not save you here.
- Are you teaching someone the mechanics?
- The HTML template plus a vulnerable lab. Tooling after they understand frames,
z-index, andopacity.
- The HTML template plus a vulnerable lab. Tooling after they understand frames,
A note on the year stamp
I will refresh this list every twelve months. The slug stays stable (best-clickjacking-tools-2026 is a redirect target you can rely on; future years update the H1 and title). Tools added, dropped, and re-ranked here will appear in the next refresh with a short changelog at the top. Double-clickjacking coverage in mainstream scanners is the thing to watch for the 2027 edition.
Where to go next
- Clickjacking: variants, exploitation, and defence for the underlying mechanics
- Cross-site request forgery for the attack clickjacking most often chains with
- Web application security vulnerabilities taxonomy for the broader map
Sources
Authoritative references this article was fact-checked against.
- Clickjacking, OWASP Communityowasp.org
- X-Frame-Options Header Scanner Rule, OWASP ZAPzaproxy.org
- Security Headers, Scott Helmesecurityheaders.com
- HTTP Observatory, Mozilladeveloper.mozilla.org
- Burp Suite, PortSwiggerportswigger.net
- DoubleClickjacking, Paulos Yibelopaulosyibelo.com
