Cookies: How Credentials Ride Along With Requests

A plain-English guide to cookies in authentication — how they automatically attach to requests, the security flags that protect them (HttpOnly, Secure, SameSite), and the CSRF risk they create.

A session gives you a session ID — but an ID is useless unless it travels with every request, automatically, without the user thinking about it. The browser mechanism that does this is the cookie. Cookies are how credentials ride along with requests, and getting their security flags right is one of the highest-leverage things you can do for web auth.

What a cookie is

A cookie is a small piece of data that the server asks the browser to store, by sending a Set-Cookie header in a response. From then on, the browser automatically attaches that cookie to every subsequent request to the same site.

Server sends Set-Cookie

Browser stores it

Browser attaches it automatically

Every later request carries it

The server sets a cookie once; the browser returns it on every request

This automatic attachment is exactly what session authentication needs. The server stores the session ID in a cookie at login, and the browser then sends it on every request with zero effort from your code — the server gets the ID it needs to look up the session each time.

The double edge of "automatic"

That automatic behavior is the cookie's greatest strength and the root of its biggest danger. It's convenient — but it means a cookie gets attached whether or not the request is one the user actually intended. Hold that thought; it's the seed of the CSRF problem at the end.

Because a cookie can carry a live session, it's a high-value target. The whole game is making sure it can't be stolen or misused. Three security flags do most of that work.

HttpOnly: hide it from scripts

The HttpOnly flag tells the browser that page JavaScript may not read the cookie. It's still sent on requests automatically, but scripts can't access its value.

Secure: HTTPS only

The Secure flag tells the browser to send the cookie only over encrypted HTTPS connections. Without it, the cookie could be sent over plain HTTP, where anyone between the user and server — on shared Wi-Fi, say — could read it straight off the wire. Since the cookie carries a live session, this flag is non-negotiable in production.

Flag	Protects against	What it does
HttpOnly	XSS stealing the cookie	Hides it from JavaScript
Secure	Interception in transit	Sends only over HTTPS
SameSite	CSRF	Limits cross-site sending

SameSite and the CSRF problem

The last flag addresses the danger we flagged earlier. Because cookies attach automatically, another website can make your browser send a request to your site — carrying your session cookie along with it.

The SameSite flag is the primary defense. It tells the browser whether to send the cookie on requests that originate from other sites:

SameSite=Strict — never send on cross-site requests.
SameSite=Lax — send only on top-level navigations, not background requests (a sensible default).
SameSite=None — always send (requires Secure; only when you truly need cross-site cookies).

Setting SameSite to Lax or Strict neutralizes most CSRF, because the malicious cross-site request simply won't carry your cookie. For sensitive actions, it's often paired with anti-CSRF tokens for defense in depth.

Recap

A cookie is data the browser stores and automatically sends on every request to a site — ideal for carrying a session ID.
That automatic sending is convenient and the source of cookie risk.
HttpOnly hides the cookie from JavaScript, blocking session theft via XSS.
Secure sends it only over HTTPS, preventing interception in transit.
SameSite limits cross-site sending — the main defense against CSRF, the attack that exploits automatic cookie sending.

Sessions store state on the server. The major alternative flips that — putting the identity in a self-contained token the client holds. That's the JWT. Continue to JSON Web Tokens (JWT).