Payloads.
Pick a vulnerability class, learn how to hunt it step by step, grab the payloads that actually work. Curated from PayloadsAllTheThings — the full section is linked under every class.
CSRF
Cross-Site Request Forgery — forcing an authenticated user's browser to send state-changing requests the app can't distinguish from theirs. The browser attaches the session cookie; the server sees a legitimate request.
Severity guide
Medium-high on state-changing actions (email/password/role changes become ATO); low on GET-only no-side-effect endpoints; SameSite=Lax defaults have reduced — not eliminated — the surface.
Where to look
entry points to test first01
State-changing endpoints
Email change, password change, transfers, role updates, deletions — anything that should require intent.
02
Settings & preferences
Notification settings, API-key generation, linked accounts — quieter but impactful.
03
Older forms & legacy flows
Endpoints predating the SPA often lack token validation entirely.
04
Cross-subdomain surfaces
User content on subdomains can attack the parent domain when SameSite isn't strict.
05
JSON APIs with loose parsing
text/plain and form-encoded JSON hybrids dodge preflight — check Content-Type handling.
How to hunt it
in order, start to finishFind state-changing actions
Email change, password change, transfers, role updates, deletions — anything that should require intent.
Strip the protections
Remove the CSRF token from the request; drop SameSite/Origin checks by replaying from another origin. If the action still succeeds, there's no real defense.
Build the PoC
GET actions: an <img src>. POST actions: an auto-submitting form with text/plain enctype where the server doesn't check the content type.
Test GET-able POSTs
Some endpoints accept both methods — the GET version with query params is trivially exploitable.
Prove the chain
Email-change CSRF + forgot-password = full ATO. The standalone bug may be medium; the chain is critical — report both.
Filter & validation bypasses
when your first tries get blocked- 01Token validated? Check token-per-session (not per-request) reuse, and non-HTTP-Only cookie tokens readable via XSS chains.
- 02SameSite=Lax assumed? Top-level GET navigations still send cookies — GET-able state changes survive Lax.
- 03Origin checked? Try null origin (sandboxed iframe), or same-site subdomain user content.
- 04Content-Type enforced? text/plain forms carry JSON-shaped bodies past preflight on sloppy parsers.
Impact ladder
what makes it payable- 01Forced account actions — email/role/password changes as the victim.
- 02Full ATO via chain — email change + reset flow.
- 03Silent state changes — transfers, orders, permissions.
- 04Chained XSS delivery — CSRF the victim into executing attacker content.
Payloads
4 · from PayloadsAllTheThings<img src="http://www.example.com/api/setusername?username=CSRFd">GET-based PoC — fires on page load, no interaction needed.
<form action="http://www.example.com/api/setusername" enctype="text/plain" method="POST">POST form PoC — text/plain dodges content-type checks on some backends.
document.getElementById("autosubmit").submit();Auto-submit — the form fires itself, victim only opens the page.
var xhr = new XMLHttpRequest(); xhr.open("GET", "http://www.example.com/api/currentuser"); xhr.send();Reading cross-origin with XHR — pairs with CORS misconfig to exfil the response.
Payload strings, code and technical terms are shown in English on purpose — payloads must be copied exactly as published.
Payloads originate from PayloadsAllTheThings (MIT) — use them only on programs you're authorized to test.