HTTP Cookies

Cookies let servers associate subsequent HTTP requests with client-side state under browser-controlled security rules. They are primarily exchanged through HTTP headers, with browsers deciding when stored cookies are sent back.

A server can send a cookie with the `Set-Cookie` response header. The browser stores it according to attributes such as `Domain`, `Path`, `Expires` or `Max-Age`, `Secure`, `HttpOnly`, and `SameSite`. Later requests that match the cookie's scope may include it in the `Cookie` request header.

Cookies are commonly used for sessions, authentication state, preferences, and other small pieces of state. A cookie is not inherently a database or authentication mechanism; it is a browser-managed mechanism for attaching values to HTTP requests.

`HttpOnly` prevents JavaScript from reading a cookie through APIs such as `document.cookie`, which reduces exposure to client-side script. `Secure` restricts transmission to HTTPS requests, while `SameSite` controls when cookies are included in cross-site request contexts and is an important defense against some CSRF scenarios.

For `fetch`, cookies are governed by the request's credentials mode. Cross-origin requests generally require an appropriate `credentials` setting for cookies to be sent, and the server must also return compatible CORS headers. Cross-site cookie use can additionally be constrained by `SameSite` and browser privacy policies.

Cookie scope matters: `Domain` can make a cookie available to matching subdomains, while `Path` limits which request paths receive it. A cookie without an explicit `Domain` is host-only, and cookie expiration determines how long the browser should retain it.

Key points

• Servers set cookies with `Set-Cookie`; browsers send matching cookies with `Cookie`.
• `HttpOnly` blocks JavaScript access, while `Secure` requires HTTPS transmission.
• `SameSite` controls cross-site cookie sending and is relevant to CSRF defenses.
• `Domain`, `Path`, and expiration attributes determine cookie scope and lifetime.
• Fetch cookie behavior depends on the request's credentials mode, origin, and browser cookie policies.

Interview questions

What is an HTTP cookie, and how does the browser use it?

A cookie is a small piece of state associated with a web origin or domain according to its attributes. A server commonly creates one using `Set-Cookie` in a response. The browser stores it and may send matching cookies in the `Cookie` header on later requests. Whether it is sent depends on attributes such as domain, path, expiration, `Secure`, and `SameSite`.

What do `HttpOnly`, `Secure`, and `SameSite` do?

`HttpOnly` prevents client-side JavaScript from reading the cookie through normal browser cookie APIs. `Secure` tells the browser to send the cookie only over HTTPS. `SameSite` controls cookie inclusion in cross-site contexts, with values such as `Strict`, `Lax`, and `None` having different behaviors. These attributes address different risks and should not be treated as interchangeable security controls.

How do cookies interact with `fetch`?

Fetch has a credentials mode that determines whether credentials such as cookies can participate in a request. For same-origin requests, the default behavior commonly permits same-origin credentials, while cross-origin requests may require `credentials: 'include'`. Cross-origin credentialed requests also need compatible CORS response headers. Even with the correct fetch setting, cookie attributes and browser privacy rules can prevent a cookie from being sent.

Why are cookies commonly used for session authentication?

A server can issue a session identifier in a cookie and use that identifier to locate server-side session state. The browser can then automatically attach the cookie to subsequent matching requests. Security-sensitive session cookies are commonly configured with properties such as `HttpOnly`, `Secure`, and an appropriate `SameSite` policy. The design still requires protection against threats such as session theft and request forgery.

What is the difference between a host-only cookie and a cookie with `Domain` set?

A cookie without a `Domain` attribute is host-only and is returned only to the host that set it. A cookie with a `Domain` attribute can be sent to matching hosts within that domain, subject to browser cookie rules. This makes `Domain` useful when related subdomains need to share a cookie, but it also broadens the set of hosts that can receive it. Cookie scope should therefore be kept as narrow as the application permits.