HTTP is described as a stateless protocol. What does that mean, and why does it matter for web applications?
Each HTTP request/response is independent — the server has no built-in "memory" linking one request to the next from the same client.
Without state, login wouldn't work — every page load would be a stranger. So web apps build state on top of HTTP:
- The server gives the client a value to remember (a "ticket").
- The client sends that value with every subsequent request.
- The server uses the value to look up the user's state.
Two mechanisms for delivering the ticket:
| Mechanism | How | When used |
|---|---|---|
| Cookie | Server sets Set-Cookie:, browser auto-sends on every request to that origin |
The default — sessions, preferences |
| Hidden form field | <input type="hidden" name="sid" value="…"> embedded in the page |
Single-step flows, anti-CSRF tokens |
Why this matters for security: every state-carrying mechanism is also an attack surface. If the attacker can guess, steal, or fix the value, they impersonate the user. The whole "Session Management" chapter exists because state was bolted onto a stateless protocol.
Tip: REST APIs sometimes use JWTs in Authorization: Bearer … headers instead of cookies. Same idea, same risks (theft, replay, expiry handling) — just a different transport for the ticket.