Keep a browser session without trusting cross-site requests.
A secure session cookie can keep a user signed in, but browsers attach cookies automatically. State-changing requests need defenses against cross-site request forgery (CSRF) in addition to session authentication.
Why this lesson?
A business web application uses a server-side session after login. It must prevent another website from causing unintended changes with the user’s session.
Learning goal and prerequisites
Sign in and create a session
After the user authenticates, the application creates an unpredictable session identifier. Sensitive session state stays on the server. The response sets the cookie with Secure and HttpOnly, and an appropriate SameSite policy.
Inspect request, response, and claims
Try a failure scenario
↳ Change a condition
Read the detailed explanation
Why it exists, how it works, and where it fits
Web applications need a way to remember that a person has already signed in. Without a session, the user would have to authenticate again on every page request. A session cookie gives the browser a small identifier that lets the server reconnect later requests to the authenticated session.
The browser automatically sends matching cookies. That convenience creates a separate risk: another website may be able to cause the browser to send a request to the signed-in application. The attacker does not need to read the cookie. If the target application accepts the automatically attached session without another check, the unwanted request may run with the victim’s authority. This is cross-site request forgery (CSRF).
Applications defend against CSRF by making state-changing requests prove that they came from the intended site or workflow. Common controls include SameSite cookie settings, unpredictable CSRF tokens, origin checks, and careful use of request methods.
Session security therefore has two parts. Protect the session identifier with controls such as Secure and HttpOnly, and separately defend sensitive actions from forged cross-site requests. A protected cookie authenticates the session; it does not by itself prove that the user intended every request carrying that cookie.
Investigation
Inspect the traffic, select a diagnosis in the checkpoint, then reveal the repair.
Check your understanding
Pass the lesson quiz
Answer every question correctly to unlock the next lesson. Retry as often as you need.