Cookie attributes explained: SameSite, Secure, HttpOnly and CHIPS

HTTP does not automatically link one request to the next as a single signed-in session. A server can send a Set-Cookie response header; the browser stores the value and may return it in a Cookie request header.

HTTP/1.1 200 OK
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

GET /account HTTP/1.1
Cookie: session=abc123

This is a schematic exchange, not a complete HTTP transcript. The value abc123 is a placeholder, not a suitable session identifier. Real session identifiers must be unpredictable.

Cookies are selected using their domain, path, expiry and security attributes, together with browser policy. Omitting Domain makes a cookie host-only. Path narrows where a cookie is sent; it is not an access-control boundary. Automatic attachment makes sessions convenient, but it also matters for cross-site request forgery (CSRF): the browser can attach credentials to a request the user did not intend.

A Secure cookie is normally sent only over HTTPS. Use this restriction for login-session cookies so they are not attached to ordinary HTTP requests.

Set-Cookie: session=abc123; Secure

Secure does not protect the value from every other threat. It does not prevent JavaScript from reading the cookie, fix session-management bugs, or stop requests triggered by an XSS attack. It is not a guarantee about storage on disk or browser extensions. Some browsers treat localhost specially; success on a local HTTP development server does not establish that the same cookie will work on a public HTTP site.

HttpOnly prevents access through document.cookie and other non-HTTP cookie APIs. This reduces the chance that an injected script can directly steal the session value.

Set-Cookie: session=abc123; Secure; HttpOnly

The browser can still attach that cookie to requests initiated by JavaScript. An XSS payload may be able to act through the victim’s session without reading its identifier.

That does not mean every fetch sends cookies. Its default credentials mode is same-origin. A request to another origin normally needs credentials: "include" to include cookies, and that option does not override SameSite or third-party-cookie restrictions. Continue to address XSS through context-appropriate output escaping, safe HTML handling and a suitable Content Security Policy; cookie attributes are only one layer.

SameSite controls whether a cookie is eligible for a cross-site request. It can reduce CSRF exposure, but it neither authorizes an operation nor replaces the server’s defenses.

Explicit Lax does not attach the cookie to a cross-site iframe request, fetch, or ordinary POST form submission. Omitting SameSite is not an interchangeable test case: some browsers allow recently created cookies on top-level POST requests as a compatibility measure, for example within two minutes of creation.

Do not treat None as an override for third-party-cookie blocking. Likewise, Lax cannot protect an application that changes state through allowed GET requests. Requests from an untrusted sibling subdomain may still be same-site. Keep appropriate CSRF tokens, Origin or Referer validation, Fetch Metadata checks and reauthentication where your application needs them.

An origin combines scheme, host and port. A schemeful site is based on the scheme and registrable domain. For ordinary top-level documents, consider these pairs:

An iframe’s ancestor documents also affect its same-site context, so comparing two hostnames is not enough for every embedded request. Ports distinguish origins, but cookies themselves are not isolated by port.

Cookie attachment, permission to read a cross-origin response, and access to another document’s DOM follow different rules. For a credentialed CORS response, Access-Control-Allow-Origin must identify the requesting origin rather than use a wildcard, and Access-Control-Allow-Credentials must be true. A CORS read failure is not proof that no request was sent or processed.

Supporting browsers enforce extra requirements when a cookie’s name starts with __Secure- or __Host-. A cookie that fails the relevant requirements is rejected.

For a host-only session, __Host- makes the scope easier to audit. Path=/ means the cookie applies across that host’s paths; it does not isolate applications by path or port. Neither prefix automatically adds HttpOnly, and neither prevents XSS.

CHIPS stands for Cookies Having Independent Partitioned State. Its Partitioned attribute adds a top-level-site partition to cookie storage while retaining the cookie’s host or domain scope. The partition’s site includes the scheme.

Set-Cookie: __Host-chat=value; Secure; Path=/; SameSite=None; Partitioned

Secure is required for Partitioned. This cross-site embedding example also uses SameSite=None: partitioning does not turn off SameSite checks.

Suppose support.chat.example sets the cookie while embedded in retail.example. When that chat service is embedded in news.example, it does not receive retail.example’s partitioned cookie. Returning to the retail site can use that site’s separate state again.

This can suit an embedded chat or another component that needs per-site state. It does not preserve one shared login across unrelated sites. In an environment that does not support Partitioned, the attribute may be ignored and the cookie may behave as an ordinary unpartitioned cookie if policy permits. Test your supported browsers rather than assuming the text of the header guarantees separation.

localStorage values are readable by JavaScript. If an attacker executes script in the application’s origin, a token stored there may be stolen directly.

An HttpOnly cookie prevents that direct read, but eligible requests still carry it. CSRF and XSS-driven requests therefore need separate defenses. The two storage choices expose different attack surfaces; neither makes session design unnecessary.

Consider token lifetime, rotation, server-side revocation, logout, reauthentication and authorization together. A storage location alone does not determine whether a session is secure.

This is a starting shape for a host-only session used by the server:

Set-Cookie: __Host-session=...; Path=/; Secure; HttpOnly; SameSite=Lax

Using an external identity provider or payment service does not automatically require None. Check whether the return journey is a top-level GET, a POST callback or an iframe. Those are different cases when choosing Strict, Lax or None.

For a widget with state that its own JavaScript reads, a partitioned cookie might instead look like this:

Set-Cookie: __Host-widget=...; Path=/; Secure; SameSite=None; Partitioned

HttpOnly is deliberately absent from the widget example because script access is part of that example’s requirement. Add it for a session value used only by the server. The ellipses are placeholders, not real secrets.

These headers illustrate attributes, not a complete authentication system. Verify browser support, cookie blocking, CORS, iframe constraints, any Storage Access API integration and the server’s authorization rules.

Secure restricts transport. HttpOnly restricts script access to the cookie. SameSite limits cross-site attachment. Partitioned separates state by top-level site in supporting environments. __Host- constrains the cookie’s scope.

None of these settings covers every threat. HttpOnly does not stop CSRF; Secure does not stop XSS; SameSite does not authorize an operation. When debugging, inspect both the stored cookie and the actual request, then check server-side CSRF, XSS and session defenses separately.