Glossary

Cookie

A cookie stores a small value in the browser. Most commonly, it carries an opaque session identifier rather than permissions or sensitive content itself.

Short definition

The server sets a value, and the browser returns it only in the defined context.

A server sends a cookie in the Set-Cookie header. The browser stores it together with rules such as the host, path, lifetime, and secure connection for which it applies. On a subsequent request to a matching part of the website, it adds the Cookie header. The HTTP request can then continue a previous visit without carrying state in the URL.

A cookie is neither a database nor a secure vault. A user can delete it in the browser, and the contents of an accessible cookie may be visible to the client. For login, a cookie therefore usually carries only a random identifier, while the session, account, and permissions remain on the server. This separates transport of the identifier from authentication and authorization.

What it is used for

Website state that the browser should attach to the next request

The server application defines the specific purpose; the same mechanism can carry a preference or an identifier for a signed-in session.

the identifier of a server-side session after signing in to administration or a customer account
a language, theme, or selected-store preference when it is reasonable to keep it in the browser
recording a cookie preference so the same decision is not requested repeatedly
short-term continuity in a form flow or a security value, depending on the application design
limited analytics and personalisation where there is a legal basis and clear privacy settings

Practical example

A signed-in user carries only the session identifier

After a successful login, the application creates a server-side session and sends a random identifier to the browser. On the next visit, the server loads the current session state by that identifier and only then checks whether the user may view a particular order. A session identifier does not belong in URLs, browser history, or Referer headers.

The setting below is a default pattern for a browser session over HTTPS. In production, SameSite must be adapted to the actual login flow and must not be treated as a replacement for CSRF protection on mutating requests.

Set-Cookie: session_id={náhodný-neprůhledný-identifikátor}; Path=/; Secure; HttpOnly; SameSite=Lax

How it works

From the server response to the next request

The browser does not send every stored cookie everywhere. It follows the attributes, domain, path, protocol, and request context.

The application creates a value The server defines the purpose of the cookie and, for a session, generates a sufficiently unpredictable identifier. Sensitive state remains on the server.
The response contains Set-Cookie Together with the value, it sets restrictions for the host, path, expiration, and security attributes.
The browser stores the cookie It may be a session cookie that expires when the browser session ends, or a persistent cookie with a defined lifetime.
The next request meets the scope rules Only then does the browser attach the matching value in the Cookie header. JavaScript normally cannot read it when HttpOnly is set.
The server treats the value as untrusted The application checks whether the session exists, is valid, or has been invalidated. It also authorizes every sensitive action on the server.

Important attributes

Cookie security comes from combining several restrictions

Attributes narrow where a browser can send a cookie or where script can access it. They do not fix an application authorization flaw.

Secure

The browser should send the cookie only over HTTPS. This attribute does not encrypt its contents and does not itself address an active attacker or flaws at another endpoint.

HttpOnly

Restricts JavaScript access to the cookie. It helps prevent direct session theft through some XSS vulnerabilities, but script may still send requests on behalf of the user.

SameSite

Controls whether a cookie is attached in a cross-site context. Lax, Strict, and None affect navigation and external login differently; this is defence in depth against CSRF.

Domain and Path

Define where the cookie applies. The narrowest necessary scope is preferable; Path is not a security boundary between parts of one application.

Max-Age and Expires

Define the lifetime of a persistent cookie. Server-side inactivity and absolute timeouts also make sense for sessions because client time is not a source of truth.

Benefits and limitations

Suitable for small state, unsuitable as a store for trusted data

Benefits

the browser attaches it automatically within a predefined scope
the server can keep sensitive state away from the client and send only an opaque identifier
Secure, HttpOnly, and SameSite provide standardised security restrictions
works without JavaScript and with ordinary HTML forms

Risks and common mistakes

storing a password, permissions, or unverified business state in a cookie
sending a session identifier in a URL, where it enters history, logs, and Referer headers
relying only on SameSite or CORS instead of CSRF checks for cookie-based mutations
setting an overly broad Domain scope or omitting Secure and HttpOnly on a session cookie

When to use it

Yes for browser flows, but not for every value

A cookie is useful when a browser should automatically return a limited identifier or user preference. For login, keeping the session and its invalidation under server control is often clear and manageable. A public API for third-party systems, by contrast, commonly uses an explicit header with an access token because the client is not a browser and automatic cookie handling adds no value.

The decision is not merely cookie versus token. You must determine who the client is, whether the flow is cross-site, how logout works, and what happens if the browser is compromised. In every variant, the server validates the input value and checks permissions for the specific resource.

What to consider

A session cookie should be simple, narrowly scoped, and predictable

Secure configuration belongs in the application, reverse proxy, and login-flow tests.

use a random opaque session identifier and never send it in a URL
set Secure over HTTPS and normally also HttpOnly and an appropriate SameSite mode for a session
limit Domain and Path to the scope actually required and verify subdomain behaviour
rotate the session identifier after login or a permission change and support server-side invalidation
test login, logout, expiration, CSRF protection, and sensitive actions without relying on the frontend

Common questions

What a cookie is and what it is not

Is a cookie automatically secure?

No. Security depends on the value, scope, and attributes. For a session, at least Secure, HttpOnly, an appropriate SameSite mode, server-side expiration, and protection of mutating requests matter.

Is a cookie the same as a session?

No. A cookie is a browser mechanism. A session is usually server-side state for which the cookie carries only an identifier.

Can a cookie contain a JWT?

Yes, but this neither makes a JWT a cookie nor solves its lifetime and revocation. Automatic cookie transmission of the token also requires a correct CSRF design.

Why not put the session ID in the URL?

URLs are stored in history, logs, analytics, and bookmarks and can be passed in the Referer. A session identifier should travel in a secure cookie, not the page address.

How I approach backends in practice

I design login and data access as one security flow.

In PHP applications, I address sessions, API boundaries, form protection, and server-side access checks according to the client and data type.

How I use PHP in practice Discuss your project without obligation