HTTP Cookies | Teleinf Edu

HTTP state and cookies

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol. A treats each request as a separate exchange. A server can still store application data, but HTTP does not require that stored state to be carried from one request to the next.

Stateless request processing can simplify load balancing because a later request does not have to reach the same server process. Applications still need a way to associate requests with a cart, a login, or a preference. A shop can use a session identifier for a cart, and a social site can use one for a login session.

An carries that identifier between requests. The server can use the identifier to retrieve session data, while the cookie itself remains a scoped name and value governed by the user agent.

Cookie exchange in HTTP

Cookie state uses the Set-Cookie response field and the Cookie request field. The user agent decides whether a stored cookie matches the request host, path, security mode, and lifetime.

Step 1: The server sets a cookie
After receiving an HTTP request, the server can send a session identifier in the response. It uses the Set-Cookie field to specify the cookie name, value, and optional attributes.
```
Server response fields
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: sessionid=abf892kds9; Expires=Wed, 21 Oct 2026 07:28:00 GMT
```
Step 2: The browser stores the cookie
The browser processes the Set-Cookie field and stores the name and value with its domain, path, lifetime, and security attributes. In this example, sessionid=abf892kds9 is associated with example.com.
Step 3: The browser sends a matching cookie
For a later request that matches the cookie's scope and security rules, the browser includes the name and value in the Cookie field. A cookie is not sent with every request to every host.
```
Client request fields
GET /products/123 HTTP/1.1
Host: www.example.com
Cookie: sessionid=abf892kds9
```
Step 4: The server resolves the session
The server reads the Cookie field and uses the identifier as a lookup key for session data, such as login status or cart contents. The application then generates a response for that session.

The browser uses cookie attributes only when deciding whether a cookie matches. The Cookie request field normally contains names and values, so the server cannot infer the expiry time, path, Secure flag, or HttpOnly flag from that field alone. The application must treat the value as untrusted input and validate the corresponding session on the server.

Cookie scope and purpose

Cookie behavior is commonly described by lifetime and scope. The server supplies attributes, and the user agent applies them when it stores and sends the cookie.

Lifetime

Session cookies: These cookies have no Expires or Max-Age attribute. The user agent retains them until its current session ends, where the meaning of session is defined by that user agent. Browser session restoration can change when such a cookie disappears. A session cookie can keep a login or cart active during a visit.
Persistent cookies: These cookies have a lifetime set with Expires or Max-Age. The user agent stores them until the lifetime ends, the user removes them, another cookie replaces them, or the user agent evicts them. They can preserve a language, theme, or sign-in preference across visits.

Site scope

First-party cookies: A first-party cookie is used in the site context of the website the user is visiting. For example, a session cookie set by example.comwhile visiting that site belongs to the site's first-party context. Its purpose depends on the application, such as a login or a preference.
Third-party cookies: A third-party cookie is used in a context where the cookie's site differs from the top-level site. An embedded service on example.com, such as a social Like button or an advertising component, can request such a cookie for its own domain. Browser settings, enterprise policy, and browser restrictions can block these cookies, so an application must handle the case in which they are unavailable.

Cookie attributes and request scope

The Set-Cookieresponse field can include attributes that limit a cookie's lifetime, host scope, path scope, transport, and script visibility.

Set-Cookie: name=value; Expires=date; Path=/; Domain=.example.com; Secure; HttpOnly; SameSite=Strict

Expires and Max-Age: Expires specifies an absolute expiration date and time. Max-Age specifies a lifetime in seconds from receipt of the field. When both are present, Max-Age takes precedence. A relative lifetime avoids dependence on the client clock used to interpret an absolute date.
Domain: This attribute specifies the hosts that can receive the cookie. If it is omitted, the cookie is host-only and is returned to the origin host. With Domain=.example.com, the leading dot is ignored and the cookie can match example.com and its subdomains, such as api.example.com and blog.example.com, subject to user-agent rules.
Path: This attribute limits the request paths for which the browser sends the Cookie field. With Path=/admin, a request to /admin/dashboard matches, while a request to /home does not. Path scope is not an access-control boundary against an active same-origin script.
Secure: If this attribute is present, the browser sends the cookie only over a secure channel, typically HTTPS over TLS. It protects confidentiality in transit, but it does not protect cookie integrity from every active network attack. Session identifiers should use Secure.
HttpOnly: When a cookie has the HttpOnly attribute, browser script APIs do not expose it. This limits cookie theft through some attacks, but an injected script can still send requests as the user. A session cookie should therefore combine this attribute with other protections.
SameSite: This attribute restricts when a browser sends a cookie with cross-site requests and can reduce some attacks. It has three values:
Strict: The cookie is withheld from cross-site requests, including a top-level navigation from another site.
Lax: The cookie is sent for same-site requests and selected top-level cross-site navigations using safe methods. User agents can apply Lax-equivalent enforcement when the attribute is omitted.
None: The cookie can be sent in cross-site contexts. This value requires Secure and is used when an embedded or federated flow needs cross-site cookie access.

A cookie can hold a session identifier or application data, but the cookie mechanism does not define the meaning of that value. Servers should keep sensitive state on the server or protect any client-held value with an appropriate integrity and confidentiality design. Scope attributes reduce exposure during ordinary requests, while authorization checks remain an application responsibility.

Privacy and browser cookie policies

Cookies can identify a browser across requests, and a cookie used in several site contexts can contribute to cross-site tracking. Third-party tracking cookies have therefore raised privacy concerns, especially when advertising or analytics services combine identifiers from many sites.

Consent and disclosure requirements depend on the jurisdiction and the purpose of the cookie. Browser vendors also restrict cross-site access through settings, storage partitioning, tracking protection, and other policies:

Third-party cookie policies: Safari blocks third-party cookies by default. Firefox blocks cross-site tracking cookies by default and can isolate other cross-site cookies. Chrome retains user controls for third-party cookies, so behavior depends on its settings and mode. Sites that depend on third-party cookies need a path for users who block them.
Tracking protection: Browsers can limit tracker storage and cross-site requests, including some uses of first-party cookies. The exact behavior depends on the browser, its settings, and the detected context.

First-party cookies remain useful for sessions and preferences, while third-party availability varies by browser and user choice. Privacy Sandbox documentation describes APIs for selected use cases such as federated sign-in, anti-fraud signals, and advertising measurement. Their availability and lifecycle depend on browser policy, so an application should define behavior both when such APIs or cookies are available and when they are blocked.