Cross-site request forgery, in one lesson
CSRF works because the browser automatically attaches cookies to any request — including requests another website triggers. If a state-changing endpoint authenticates the user with cookies alone and lacks any anti-CSRF defence, an attacker page can act on behalf of the logged-in victim.
What to check on every endpoint
The endpoint accepts POST, PUT or DELETE. It is authenticated by cookie alone, with no Authorization header and no token in the body. The session cookie does not have SameSite=Lax or Strict. There is no CSRF token, or the token is not actually validated on the server side. Any endpoint that ticks all four boxes is exploitable.
A classic proof of concept
Build a tiny HTML page that contains a form pointing at the target endpoint, with the form fields set to whatever the attacker wants to change — typically the victim's email address. Add a small script that auto-submits the form. Host the page and trick the victim into visiting it while they are logged in. The browser submits the form, the cookie is attached, the email gets changed, the password reset email arrives at the attacker, and the account is taken over.
Modern reality in 2026
Browsers default cookies to SameSite=Lax, which kills classic POST-based CSRF for cross-site requests. So in 2026 your hunt focuses on the surfaces where Lax does not protect: GET-based state changes, top-level navigation forms, JSON endpoints that read text/plain content-type to dodge CORS preflight, and applications that explicitly set SameSite=None for legacy iframe support. There is still plenty of CSRF to find — you just have to know where it lives now.
