What Is a Session Cookie? – Definition and How It Works
Learn what a session cookie is, how it differs from a persistent one, how server-side sessions work, and which attributes protect it.
A session cookie carries no expiry date, so the client discards it when the browsing session ends. It is the usual vehicle for login state, which is why closing a browser often logs you out.
1. Session Versus Persistent
| Session cookie | Persistent cookie | |
|---|---|---|
| Expiry attribute | Absent | Expires or Max-Age set |
| Survives browser close | No | Yes, until expiry |
| Typical use | Authentication, temporary state | Preferences, consent records, long-lived sign-in |
Note that "session" here means the browser's session, not the server's. A server-side session can outlive the cookie that referenced it, and often does.
2. What It Usually Contains
Most implementations store only an opaque identifier in the cookie, with the actual session state held server-side.
Set-Cookie: sid=8f2a...; Path=/; HttpOnly; Secure; SameSite=Lax
That indirection keeps state off the client, allows server-side revocation, and limits what an intercepted cookie reveals.
3. The Protective Attributes
HttpOnly— hides the cookie from page scripts, limiting theft via injected code.Secure— sends it only over HTTPS.SameSite— controls whether it travels on cross-site requests, mitigating cross-site request forgery.PathandDomain— narrow where it is sent.
For an authentication cookie, the first three should be considered mandatory.
4. Server-Side Sessions
The server keeps state keyed by the identifier — in memory, a cache, or a database — and looks it up on each request.
Its advantages are immediate revocation, size freedom, and keeping data off the client. Its cost is shared storage, which becomes a coordination problem once more than one server is involved.
5. Token-Based Alternatives
Signed tokens carrying claims avoid server-side lookup by making the credential self-contained. That gains scalability and loses easy revocation, since a valid token remains valid until it expires.
The choice is genuinely a trade-off, and short lifetimes are how token systems compensate.
6. Why This Matters for Automation
Any flow spanning requests depends on returning the session cookie. Discard it and every request looks like a first visit — repeating logins, consent dialogs, and challenges.
Two related rules follow: keep the cookie jar for the whole task, and do not change egress address mid-session, since server-side state is often bound to the address that created it.
7. Storing and Reusing Sessions
Exported session state is credential-equivalent and must be protected accordingly. It also expires, and a restored session that silently no longer authenticates produces results that look like a content change rather than an auth failure — which is why validating the session before a run is worth the extra request.
8. Summary
A session cookie has no expiry and is discarded when the browser session ends, typically holding an opaque identifier for server-side state.
Protect it with HttpOnly, Secure, and SameSite; preserve it across a task in any automated flow; and treat any exported copy as a credential.