Files
What you'll learn
- Explain a CSRF attack step by step, and why it needs credentials the browser attaches on its own (cookies) and cannot touch a bearer-token API
- Describe the double-submit cookie pattern: a token in a cookie and the same token in a header, which a foreign page cannot read
- Configure csrf-csrf with a secret, a session identifier, a cookie and a header, and mount it after cookie-parser on the routes that change state
- Read the 403 the middleware answers and know why a token from before sign-in stops working after
Press Run tests to start the app. Its log appears here.Graded endpoints
Reading is public and never CSRF-checked: no cookie, no token, a 200
Public too; the 404 is the handler's, so the guard let the request through
Middleware runs before guards: with no token the CSRF check refuses first, before anyone asks who is signed in
Issued for the anonymous session; the cookie half is set alongside. Kept, to try later
The token goes into an httpOnly cookie, which the request panel keeps like a browser would
No Authorization header: the guard read the token from the cookie the browser sent by itself. Exactly the property an attacker relies on
Bound to john's cookie now; the page would fetch this after signing in
Signed in, cookie sent, and still refused: the cookie alone is what a forged request would carry
The token from before signing in was bound to another session identifier, so it no longer validates
Cookie and header agree and match the session: only a page that could read the token can do this
GET changes nothing, so it is never checked; a protected GET would break every link to the site
Unchecked as well
Every method that changes state is checked, DELETE included
The same token serves the whole session