Why do web applications need session IDs at all?
HTTP is stateless — each request stands alone — so after login the server hands the browser a session ID and uses it to recognise that all later requests belong to the same authenticated user.
* Log in once, then the cookie carries the session ID on every request so the server keeps recognising you. *
HTTP has no built-in memory: on its own, the server can't tell that the request loading your shopping cart comes from the same person who logged in a moment ago — every request looks brand new. A session bridges that gap:
- On successful login the server creates a session (server-side state: who you are, your privileges) and generates a long, random session ID.
- It sends that ID to the browser, normally as a cookie.
- The browser returns the ID on every later request, so the server looks up the matching session and treats the request as authenticated.
This is why the session ID is so sensitive: it is the proof of being logged in. Anyone who obtains a valid session ID is, as far as the server is concerned, that user — which is exactly what session hijacking and fixation go after.
Go deeper:
HTTP cookie (Wikipedia) — how cookies carry the session ID between requests, plus the session-management and security sections.