What is CSRF and how do you verify that a protection mechanism is working?

CSRF exploits the fact that browsers automatically attach cookies to cross-origin requests. If a user is logged into bank.com and visits attacker.com, attacker.com's page can submit a form to bank.com/transfer and the browser will include bank.com's session cookie — making the request appear to come from the authenticated user.

How CSRF tokens prevent this: the server issues a secret token (distinct from the session cookie) that must be included in state-changing requests. Since attacker.com cannot read the token from bank.com's responses (same-origin policy), it can't forge a valid request.

Testing the token validation:

1. Capture a legitimate state-changing request (POST, PUT, DELETE, PATCH) that includes the CSRF token.
2. Replay the request with the token removed from the body/header.
3. Replay the request with the token replaced by a known-invalid value.
4. Assert: both replays receive 403 or 422. A 200 or a successful state change is a failure.

Testing SameSite mitigation (the modern alternative to CSRF tokens):

1. Verify the session cookie has SameSite=Strict or SameSite=Lax.
2. Confirm cross-origin POST requests do not include the cookie (by observing the request from a different origin in a browser proxy).

Endpoints to prioritise: password change, email change, money transfer, account deletion, user role modification — any endpoint that changes security-relevant state.