From session-jwt-security: when you log in, the server issues a session cookie that the browser stores and attaches automatically to every subsequent request to that site — you do not add it manually. That automatic attachment is what makes sessions convenient, and it is also what makes forgery possible.
Cross-site request forgery (CSRF) tricks a logged-in victim's browser into sending a state-changing request that the application processes as if the victim had intended it. The attacker never steals a password or a token — they borrow the victim's already-authenticated session through the ambient authority of the session cookie.
In this lesson you will:
- Understand why the browser attaches the victim's session cookie to a request triggered by an unrelated attacker page, and what the Same-Origin Policy (SOP) does and does not stop.
- Inspect NovaCart's username-change form at
/profileand confirm it relies only on the session cookie, with no anti-CSRF token. - Author a minimal auto-submitting HTML form that forges the username change — the core of NovaCart's CSRF challenge.
- Identify the durable defenses: server-issued anti-CSRF tokens, the double-submit cookie pattern, and **
SameSitecookies, plus why cross-site scripting** defeats all of them.
Estimated time: 10 to 15 minutes.
Prerequisites: complete session-jwt-security and browser-security-model first — CSRF is meaningful only against an authenticated session, and step 3 builds on the Same-Origin Policy introduced in that browser security lesson. Step 4 asks you to write a minimal HTML form, so a working knowledge of basic HTML (from web-technology-primer) is also needed. Register a normal user account in NovaCart and log in before you begin.
When you are ready, send the Continue signal.