The Best CSRF Tools in 2026

A tools listicle is only useful if the author is honest about the landscape. CSRF in 2026 is mostly a solved class: browser SameSite=Lax defaults closed the door on the bulk of historical exploitation. The remaining live cases are narrow, and so is the tooling. This is the short list of CSRF tools I have spent real engagement hours with this year, with notes on where each fits, where each falls short, and where you should not waste time at all.

If you want the underlying mechanics first, the cross-site request forgery deep dive covers the variants and modern attack surface. This article is for the choice of which tool to run. The broader web application security vulnerabilities taxonomy puts CSRF next to its frequent travel partners, cross-site scripting and clickjacking.

Honest framing: where CSRF stands in 2026

Before the matrix, the framing matters. Chrome shipped SameSite=Lax-by-default for new cookies in 2020, and the long tail of holdouts has caught up. That single change neutered classic cross-origin form-POST CSRF for the vast majority of cookie-authenticated sessions. The cases still worth testing in 2026:

• JSON API endpoints without CSRF tokens or Origin validation. Especially APIs that accept Content-Type: application/json from a fetch with credentials: 'include' and rely solely on the cookie.
• File-upload and multipart endpoints where the framework's CSRF middleware is bypassed by the multipart parser or by an enctype quirk.
• Top-level navigation POSTs within the 2-minute Lax window (some browsers honour a short grace window for top-level POSTs on newly-set cookies).
• Cross-subdomain CSRF where a SameSite=Lax cookie is still in scope and a subordinate host has an HTML-injection or open redirect.
• State-changing GETs. Always worth checking; they bypass SameSite=Lax-by-default entirely if the cookie is Lax (Lax permits top-level GET).

The tooling reflects this: there is no "sqlmap for CSRF" because the defence is largely won and the residual cases are case-by-case. The good tools generate PoCs and surface missing tokens quickly so you can spend your time on the interesting edges.

The decision matrix

A quick read of the table: Burp's PoC generator is the canonical attacker workflow. ZAP is the open-source equivalent. xsrfprobe and Param Miner help with discovery. Everything past that is manual.

1. Burp Suite CSRF PoC generator (Engagement tools)

Site: portswigger.net/burp, CSRF PoC generator

The canonical CSRF workflow. Right-click, Engagement tools, Generate CSRF PoC.

Burp's PoC generator takes any captured request, analyses the body type (urlencoded form, multipart, JSON, plain text), and writes a self-contained HTML page that reproduces the request from a third-party origin. For multipart and urlencoded form posts it produces a real <form> with hidden inputs; for JSON it falls back to fetch with credentials: 'include' (which is where you find out whether the target validates Origin or just hopes the cookie is enough).

What I like:

• Zero friction. Capture the state-changing request once, right-click, done. The output is a single HTML file you can host anywhere.
• Handles the awkward bodies correctly. Multipart boundaries, base64-binary fields, JSON, all generated without manual escaping.
• The auto-submit checkbox flips the PoC from "manual click to fire" to "loads and fires immediately on visit", which is the realistic attacker payload.
• Integrates with the rest of Burp. Capture in proxy, shape in Repeater, then generate the PoC from the final shape.

What I do not like:

• Pro-only. The Community edition does not have the Engagement tools menu. Around 500 USD per user per year, same licence as for SQLi work.
• The JSON-body PoC is necessarily a fetch call, which most modern browsers will reject as a non-simple cross-origin request without a preflight that fails on the target. Useful as a Same-Origin demo but rarely a viable cross-site exploit in 2026.
• No batch mode. One request at a time.

When to use it. Always, the moment you find a request that looks state-changing and the response sets/uses a session cookie. The PoC takes ten seconds to generate and either fires or surfaces exactly what defence the app has in place.

2. OWASP ZAP

Site: zaproxy.org

The open-source equivalent. Built-in anti-CSRF token tracking and a CI-friendly API.

ZAP is the long-standing free alternative to Burp. For CSRF specifically it has two useful pieces: configurable Anti-CSRF Tokens (you tell ZAP which parameter names carry tokens, and the active scanner fetches a fresh one before each test request), and an Active Scan rule that flags forms missing tokens or with predictable token patterns. Forms-Based Authentication handles the login-then-replay loop that CSRF testing depends on.

What I like:

• Free and scriptable. The headless mode plus REST API integrate cleanly into CI for regression checks ("did we ship a new endpoint with no CSRF defence this sprint?").
• Anti-CSRF token configuration is genuinely useful. Without it, every scanner request fails on the token check and you get no signal at all on the underlying parameter handling.
• The Forms-Based Authentication plus session-management combo replays logins automatically when the session expires mid-scan.

What I do not like:

• The UI is dense. The Burp learning curve is gentler; ZAP's option panels go three or four levels deep before you find what you need.
• No equivalent of Burp's one-click PoC generator. You generate PoCs by hand from the captured request, or write a small HTML wrapper script.
• The active scan rules for CSRF are conservative and produce false negatives on JSON APIs.

When to use it. Open-source engagements, CI integration, or when the client policy precludes commercial tooling. Also pairs well with Burp: run ZAP headless for the regression coverage, Burp interactively for the depth.

3. Burp Param Miner

Repo: github.com/PortSwigger/param-miner

Useful for finding the hidden CSRF token name when the obvious candidates are absent.

Param Miner brute-forces parameter names against a target endpoint and detects which ones the server actually reads (typically by response diffing). For CSRF work this matters when the app uses a non-standard token name: not csrf_token or authenticity_token, but _t, xsrf, nonce, request_id, or a framework-specific value. If you cannot find the token parameter you cannot test what happens when it is missing or wrong.

What I like:

• Finds parameters the proxy history never shows. Many tokens are issued in one endpoint and consumed in another with no visible link.
• The bundled wordlists cover the common token names well; custom wordlists are a single text file.
• Works for header parameters too, which catches the increasingly common pattern of CSRF defence via a custom header rather than a body field.

What I do not like:

• Burp Pro requirement for full Intruder-driven mode. The free-extension version is rate-limited.
• Noisy on the target. Hundreds of probe requests; tune the delay and the wordlist before pointing it at production.
• Findings need interpretation. A "discovered parameter" is not necessarily a CSRF token.

When to use it. Whenever the request looks like a state-changing call but no obvious token parameter exists in the body or headers, and the obvious names ("csrf", "token", "authenticity") are not present.

4. xsrfprobe

Repo: github.com/0xInfection/XSRFProbe

The closest thing to a sqlmap-for-CSRF. Use with care; maintenance is light.

XSRFProbe by 0xInfection crawls a target, enumerates its forms, and tests each one for missing CSRF tokens, token predictability, token reflection, and SameSite-cookie posture. It can also generate a basic HTML PoC for any form it flags.

What I like:

• Genuinely useful for the discovery half. Point it at a target, get back a list of forms grouped by token status.
• Output is grep-friendly. JSON option for tooling pipelines.
• One of the only open-source tools that even attempts CSRF batch scanning.

What I do not like:

• Maintenance is light. Long stretches between commits; some open issues sit unresolved.
• False positive rate on modern frameworks. Many apps put the token in a header or a separate fetch, and xsrfprobe reads "no token in form" as a finding.
• No JSON-API support to speak of. Form-centric, which is the half of the surface that SameSite already defends.

When to use it. As a first-pass discovery against a target with many traditional HTML forms (admin panels, CMS backends). Always confirm findings by hand before reporting; the false-positive rate is real.

Typical command:

xsrfprobe -u https://target.example -c 2 --user-agent "Mozilla/5.0"
xsrfprobe -u https://target.example --crawl --output report.json

5. Manual Origin and Sec-Fetch-Site testing

Site: there is no single tool. The workflow is curl plus Burp Repeater.

The cases automation cannot reach. This is half of real-world CSRF testing in 2026.

Modern CSRF defence often relies on the Origin header (sent on state-changing cross-origin requests by all current browsers) or the Sec-Fetch-Site fetch metadata header (same-origin, same-site, cross-site, none). The question is: what does the server do when those headers are present, absent, or hostile? The answer is request-by-request, and no scanner handles it cleanly. The workflow:

1. Capture the state-changing request in Burp. Send it to Repeater.
2. Send the baseline. Confirm it succeeds.
3. Strip the Origin header entirely. Resend. Many apps fall over because they require Origin to be present; some accept whatever happens to be there. Both outcomes are bugs of a sort.
4. Set Origin: https://attacker.example. Resend. If the request succeeds, the Origin check is absent or broken.
5. Set Sec-Fetch-Site: cross-site. Resend. Genuinely modern defences check this; most do not.
6. Try the request with no cookies but with a Bearer token (if the API supports both). If the API ignores Origin when the auth is a header, that is a separate finding.

What I like:

• It is the only way to reliably test the headers-based defence in 2026. Scanners do not cover this well because the correct interpretation is target-specific.
• Fast. Five minutes per endpoint once you have the request captured.

What I do not like:

• Manual. Does not scale. You pick the endpoints that matter and test those by hand.
• Easy to miss a defence-in-depth layer. A request can succeed in Repeater but still be blocked by a cookie SameSite attribute that only matters cross-origin.

When to use it. Always, on the handful of endpoints that actually carry the security-relevant state changes (auth changes, payment, role grants, data export). Skip it on idempotent read-only endpoints.

6. Mozilla Observatory and securityheaders.com (defensive)

Sites: observatory.mozilla.org, securityheaders.com

Defensive scanners. Useful for the defence side of the engagement, not the attack side.

Neither tool tests CSRF directly, but both grade the headers and cookie attributes that affect a CSRF posture: Content-Security-Policy (limits where embedded forms can submit to), SameSite cookie attribute (the primary 2026 defence), Set-Cookie flags more broadly, and the security-headers cluster (X-Frame-Options, Referrer-Policy, Permissions-Policy).

What I like:

• Free, hosted, no setup. Useful for the report appendix and for client conversations.
• Mozilla Observatory's scoring is well-calibrated and the explanations are good.
• securityheaders.com is faster for a quick check; Observatory is the more thorough audit.

What I do not like:

• Both are header-grading tools. They do not test behaviour. A site can score A+ and still be exploitable on a JSON API endpoint with no Origin check.
• The grade is a starting point for the conversation, not the verdict.

When to use it. Defensive engagements, hardening recommendations, the report appendix. Not a substitute for any of the attacker-side tooling above.

What I do not recommend

Old-generation CSRF scanners (Pinata-csrf-tool, csrf-tester)

There was a generation of CSRF-specific scanners in the 2010s. Most are abandoned, none model modern defences (SameSite, Origin, Sec-Fetch-Site, double-submit cookie patterns, custom-header tokens). Running them against a 2026 target produces noise. Burp's PoC generator, ZAP's active scan, and xsrfprobe cover everything the older tools did, with the defences understood correctly.

Skip them.

"All-in-one web vulnerability scanners" for CSRF specifically

Several commercial scanners advertise CSRF as one of fifty checks. In practice the CSRF check is a heuristic ("is there a parameter that looks like a token?") that produces high false-positive and false-negative rates. The scanner output is at best a list of endpoints to test by hand; you may as well skip the scanner.

Tools I dropped from this year's list

• Pinata-csrf-tool. Last meaningful commit predates this year by years. Form-only, no JSON support, no modern-header testing.
• csrf-tester (Burp extension, original). Subsumed by the built-in Engagement tools PoC generator and by Param Miner for the discovery half.
• Bolt. Reflected-XSS focused with a CSRF sidebar; the CSRF coverage is too thin to recommend as a CSRF tool. If reflected XSS is the goal, fine; for CSRF, no.

Which tool should I use? (Decision tree)

A short flow for the common cases:

• Is the request a classic HTML form POST with cookie auth?
  • Yes. Burp's CSRF PoC generator. Test it. If it fires from a third-party origin, write it up. If it does not, look at the cookie's SameSite attribute and the Origin check in Repeater.
• Is the request a JSON API call with Content-Type: application/json and credentials: 'include'?
  • Yes. Manual testing in Repeater. Strip Origin, swap Origin, drop the CSRF header if there is one. The PoC will not fire cross-origin in any modern browser, but the server-side check is still worth verifying.
• Is the request a state-changing GET?
  • Yes. Test it as CSRF immediately. SameSite=Lax does not block top-level GETs. State-changing GET is the residual classic case.
• Are you scanning an admin panel or CMS with many forms?
  • Yes. xsrfprobe first pass, then Burp PoC generator on anything it flags.
• Are you on an open-source-only engagement?
  • Yes. OWASP ZAP for the proxy and active-scan piece; xsrfprobe for batch discovery; manual Repeater work for the headers-based testing.
• Are you writing the defence-side report?
  • Yes. Mozilla Observatory and securityheaders.com for the headers grade, then your manual findings on top.

Where to go next

• Cross-site request forgery: variants, exploitation, and defence for the underlying mechanics
• Cross-site scripting for the class that frequently chains with CSRF
• Clickjacking for the UI-level analogue that survives some CSRF defences
• Web application security vulnerabilities taxonomy for the broader map