Cookies and Sessions over HTTP

Why it matters

Almost every feature behind a login depends on this mechanism, and many of its defects are security defects: a session identifier that scripts can read, that travels over plain HTTP, that still works after logout or that never expires lets someone else act as the user. None of this shows in a happy-path run.

The checks are cheap and concrete: developer tools and a test account show whether an attribute is present and whether a replayed request is refused, and a report quoting the exact Set-Cookie line lets a developer fix the configuration quickly.

Scope and lifetime: Domain, Path, Expires and Max-Age

A server sets one cookie per Set-Cookie header: name=value, then attributes. RFC 6265 defines how the browser stores it and which requests receive it. The browser returns only the name=value pairs, in one Cookie header, so check attributes in the response, not in the request.

• Domain: without it the cookie is host-only and returns only to the host that set it; Domain=portal.example also sends it to every subdomain, such as docs.portal.example.
• Path: the cookie goes to URLs whose path starts with the cookie path at a / boundary, so Path=/help matches /help/start but not /helpdesk. RFC 6265 warns that Path is not a security boundary.
• Expires (a date) or Max-Age (seconds) makes the cookie persistent, and Max-Age wins if both are set. Without either it is a session cookie, dropped when the browser session ends. Max-Age=0 deletes it.
• A cookie is identified by name, domain and path together. A delete or overwrite must repeat all three; otherwise the old cookie stays, and an overwrite only adds a second cookie with the same name.

Responses from https://portal.example
Set-Cookie: sid=k3Vq9XbT2mR7wLp4; Path=/; Secure; HttpOnly; SameSite=Lax
Set-Cookie: lang=ar; Domain=portal.example; Path=/; Max-Age=31536000; Secure
Set-Cookie: tour=done; Path=/help; Expires=Fri, 01 Jan 2027 00:00:00 GMT; Secure

Request to                               Cookies the browser sends
https://portal.example/help/start        sid, lang, tour
https://portal.example/dashboard         sid, lang
https://docs.portal.example/             lang

Try it: Cookie Analyzer Try it: URL Parser

Security attributes: Secure, HttpOnly and SameSite

These attributes limit how a cookie can leak or be misused. Each one blocks one path, so know what it does not block.

• Secure: the cookie is sent only over HTTPS, so it cannot be read from plain HTTP traffic.
• HttpOnly: the cookie is hidden from document.cookie, so an injected script cannot copy it, but the browser still attaches it to requests, so such a script can still act as the user inside the page.
• SameSite controls requests that start on another site. Strict: never sent, so a user arriving from another site's link looks logged out. Lax: sent only on top-level navigations, where the whole tab moves to the site (for example by following a link), with a safe method such as GET; not on cross-site form posts, images, frames or fetch calls. None: sent on cross-site requests too, unless browser settings block third-party cookies, and accepted only with Secure.
• A "site" is the registrable domain, so docs.portal.example is the same site as portal.example. SameSite comes from the RFC 6265bis drafts that browsers implement, not from RFC 6265, and defaults differ between browsers, so expect it to be set explicitly.
• Baseline for a session cookie: Secure, HttpOnly, an explicit SameSite=Lax or Strict, no Domain unless subdomains need it, and no Expires or Max-Age, because the OWASP Session Management Cheat Sheet recommends non-persistent session cookies.

Try it: Cookie Analyzer Try it: HTTP Headers Parser

Server-side sessions: identifier, expiry and logout

At login the server keeps a session record (user, roles, times) in a session store such as memory, a database or a cache, and sends only a random identifier in Set-Cookie. Each later request is looked up by that identifier: a live session runs it as that user; otherwise a page is redirected to the login page and an API returns 401 Unauthorized.

So there are two clocks, the cookie's in the browser and the session's on the server, and only the server's protects, because whoever holds the identifier can keep sending it. The OWASP Session Management Cheat Sheet calls for:

• An identifier from a cryptographically secure random generator, with at least 64 bits of entropy (a measure of how hard it is to guess) and no meaning such as a user id or a timestamp.
• A new identifier at login and at every privilege change, with the old one invalidated; otherwise an identifier planted before login (session fixation) still works after it.
• An idle timeout counted from the last request and an absolute timeout counted from login, both enforced on the server.
• A logout that ends the record on the server; deleting the cookie with Max-Age=0 only tidies the browser.
• The identifier only in the cookie, never in the URL, where it leaks into history, logs and Referer headers.

Worked example: tracing and testing a login session

A staff portal in a test environment, https://portal.example, requires: "A session ends after 15 minutes without activity and 8 hours after login. Log out ends the session." With a test account and the Network panel open, the tester logs in, opens the dashboard, logs out and records the exchange below.

Test only systems you own or are allowed to test, and mask session identifiers in reports, since a copied live identifier works like a password. Each check becomes a test case:

• Attributes: sid has Secure, HttpOnly and SameSite=Lax, and no Domain or Max-Age.
• Renewal: the site gave the anonymous visitor a session before login (Ae5f…); that value differs from the new one and, when replayed, lands on the login page.
• Logout: the delete repeats Path=/, and replaying the old value with curl (-i prints the response headers, -H adds a request header), for example curl -i -H "Cookie: sid=k3Vq9XbT2mR7wLp4" https://portal.example/dashboard, returns a redirect to /login, never dashboard data.
• Idle timeout at its boundary: network delay and the server's timer make the exact second unreliable, so agree on a small margin and test both sides, for example a request after 14 min 50 s idle (still works) and one after 15 min 10 s (login page). Ask whether the test environment can use shorter timeouts.
• Absolute timeout: despite steady activity, the session ends 8 hours after login.
• Scope: docs.portal.example never receives sid.

POST /login HTTP/1.1
Host: portal.example
Cookie: sid=Ae5fUq0Zr8Ty2Nc6

HTTP/1.1 303 See Other
Location: /dashboard
Set-Cookie: sid=k3Vq9XbT2mR7wLp4; Path=/; Secure; HttpOnly; SameSite=Lax

GET /dashboard HTTP/1.1
Host: portal.example
Cookie: sid=k3Vq9XbT2mR7wLp4

POST /logout HTTP/1.1
Host: portal.example
Cookie: sid=k3Vq9XbT2mR7wLp4

HTTP/1.1 303 See Other
Location: /login
Set-Cookie: sid=; Path=/; Max-Age=0; Secure; HttpOnly; SameSite=Lax

Try it: Cookie Analyzer Try it: cURL Generator

Frequently asked questions

References

• RFC 6265: HTTP State Management MechanismIETF · 2011How cookies are set and sent: the Set-Cookie attributes (Expires, Max-Age, Domain, Path, Secure, HttpOnly) and their scope rules.
• OWASP Cheat Sheet Series: Session ManagementOWASP FoundationSession identifier entropy, cookie attributes, expiry, renewal after login and logout handling.
• Using HTTP cookies — MDNMDN Web Docs (Mozilla)Cookie lifetime, scope, the Secure/HttpOnly/SameSite attributes and their security implications.
• OWASP Cheat Sheet Series: Cross-Site Request Forgery PreventionOWASP FoundationCSRF defences: synchronizer tokens, SameSite cookies and origin checks.