Introduction
HTTP has no memory. Every request arrives with no knowledge of the one before it. Everything you know about "being logged in" is a workaround for that fact, and most authentication bugs come from misunderstanding the workaround.
How it works
You submit credentials. The server verifies them, creates a session record, and hands back an identifier in a cookie. Every later request carries that cookie, and the server looks up the session to decide who you are.
That identifier is now equivalent to your password for the lifetime of the session. Anything that lets an attacker read it, guess it, or fix it in advance is a full account compromise — which is why the interesting attacks target the identifier rather than the password.
Common risks
A session identifier that survives login unchanged allows session fixation. One transmitted over plain HTTP can be read in transit. One readable by JavaScript can be stolen through XSS. One that never expires stays valid long after a laptop is lost.
How to detect it
Check whether the identifier changes at the login boundary. Confirm Secure, HttpOnly and SameSite are set. Look at expiry — both idle and absolute. Test whether logout actually invalidates server-side or merely clears the cookie.
How to defend
Regenerate the session identifier on every privilege change. Set Secure, HttpOnly and SameSite=Lax or Strict. Enforce idle and absolute timeouts. Invalidate server-side on logout. Bind sensitive actions to re-authentication rather than to session age alone.