Separate cookies, origins, and sites

A cookie is selected by several independent rules

Set-Cookie asks a user agent to store a cookie with a name, value, and attributes. Later, the user agent selects applicable cookies for a request and serializes their name/value pairs in Cookie. The server does not receive the original attributes back in that request field.

Set-Cookie: session=opaque; Path=/app; Secure; HttpOnly; SameSite=Lax

Expected result: a supporting browser stores an HTTP-only cookie scoped to secure requests and the /app path, subject to its same-site rules. The line does not make the cookie encrypted storage, and the opaque value should not contain a secret that is safe merely because JavaScript cannot read it.

Host and path scope are not origin scope

An origin is a tuple of scheme, host, and port. Cookie host matching does not use the port, and the Path attribute limits when a cookie is sent without creating a security boundary between applications on the same host.

Omitting Domain creates a host-only cookie. Supplying an accepted Domain allows the cookie to apply to that domain and matching subdomains. A server cannot set a cookie for an unrelated domain.

A site is another boundary

Same-site calculations group related origins by scheme and registrable domain under the current cookie model. Two subdomains can be same-site while remaining cross-origin. Moving from HTTP to HTTPS can change the site relationship even when the host is unchanged.

SameSite influences whether a cookie is sent in cross-site contexts. It does not replace CSRF defenses by itself and does not grant JavaScript access to a response.

Secure, HttpOnly, and credentials solve different problems

Secure limits cookie transmission to user-agent-defined secure channels. HttpOnly withholds it from non-HTTP APIs such as document.cookie. Neither attribute changes Domain, Path, expiry, or SameSite matching.

Browser fetch credentials settings determine whether credentials may accompany a request and whether Set-Cookie is honored in that context. CORS separately determines whether script can read a cross-origin response. Diagnose storage, selection, sending, and response access as separate steps.

Treat evolving browser behavior as compatibility-sensitive

SameSite processing, cookie prefixes, storage partitioning, and privacy controls continue to evolve. This page cites the current HTTP Working Group draft for the modern model and uses a six-month review interval. Test supported browsers for the specific context instead of assuming one default covers every version.