Cybersecurity glossary
What is a Cookie?
Learn what an HTTP cookie is, how browsers store and send cookies, how Path Domain and Secure attributes shape scope, and which security controls protect session state.
Definition
A cookie is a small piece of data that a website asks a browser to store and then automatically include on later requests to matching URLs, enabling session continuity, preferences, and other stateful behavior across otherwise stateless HTTP interactions.
Why cookies matter
HTTP is stateless: each request stands alone unless the application adds memory. Cookies are the browser’s built-in way to carry that memory. Login sessions, shopping carts, language choices, and many analytics identifiers ride on cookies.
Because browsers attach matching cookies automatically, they are powerful and dangerous at the same time. A stolen session cookie can become account takeover. A loosely scoped cookie can leak across subdomains. Understanding cookies is foundational web security literacy.
How cookies work
Servers set cookies with Set-Cookie response headers. Browsers store them and later send a Cookie request header when URL, domain, path, and attribute rules match.
Server issues Set-Cookie
The response includes a name/value pair plus optional Domain, Path, Expires/Max-Age, Secure, HttpOnly, SameSite, and related flags.
Browser stores the cookie
The cookie jar keeps the value with its scope and security metadata for the profile.
Later request matches scope
Scheme, host, path, and SameSite rules decide whether the cookie is eligible to send.
Browser attaches Cookie header
Eligible cookies are included automatically without application JavaScript.
Application restores state
The server reads the cookie to continue a session, personalize content, or apply preferences.
Core attributes that define behavior
Name and value
The payload the application relies on. Keep values opaque identifiers rather than encoding secrets or PII when possible.
Domain and Path
Control which hosts and URL paths may receive the cookie. Broader scope increases sharing and risk.
Lifetime
Session cookies vanish with the browser session; persistent cookies use Expires or Max-Age.
Security flags
Secure, HttpOnly, and SameSite shape transport, script access, and cross-site sending behavior.
Cookie types you will encounter
| Type | Meaning | Security note |
|---|---|---|
| Session cookie | Typically lives for the browsing session | Still stealable if exposed; short life helps but is not enough alone |
| Persistent cookie | Survives restarts until expiry or deletion | Long-lived auth cookies raise theft impact |
| First-party | Belongs to the site the user is visiting | Primary vehicle for application sessions |
| Third-party | Set or sent in cross-site embedded contexts | Heavily restricted by modern browsers for privacy |
Security checklist for cookie design
- Store session identifiers in cookies, not passwords or raw tokens you cannot revoke easily.
- Mark authentication cookies Secure and HttpOnly unless there is a documented exception.
- Choose SameSite=Lax or Strict for first-party sessions; use None only with Secure when cross-site sending is required.
- Avoid Domain=.example.com unless every subdomain is equally trusted.
- Keep Path as narrow as practical for sensitive cookies.
- Rotate session IDs after login and privilege changes.
- Prefer cookie prefixes (__Host- / __Secure-) for high-assurance cookies when compatible.
- Clear cookies on logout and invalidate server-side session state.
Common failure modes
Cookies fail open when attributes are missing, when subdomains share a broad Domain, when XSS can read non-HttpOnly tokens, or when cross-site requests still carry cookies useful for CSRF. Caching layers that store Set-Cookie incorrectly can also leak sessions between users.
Another frequent mistake is treating cookie presence as proof of strong authentication without binding sessions to server-side state, device signals, or step-up checks for sensitive actions.
The practical takeaway
A cookie is browser-managed state that HTTP requests can carry automatically. That convenience powers the modern web and creates a concentrated trust surface around session continuity.
Design cookies deliberately: minimize what they contain, constrain where they travel, harden them with security attributes, and assume that anything readable by script or sent too broadly will eventually be abused.
Related security terms
HttpOnly Cookie
Attribute that blocks JavaScript access to a cookie via document.cookie.
Secure Cookie
Attribute that restricts cookie transmission to HTTPS requests.
SameSite Cookie
Attribute that controls when cookies are sent on cross-site requests.
First-Party Cookie
Cookies scoped to the site the user is actively visiting.
Cross-Site Request Forgery (CSRF)
Attack class that abuses automatic cookie attachment on cross-site requests.
Frequently asked questions
What is a cookie in simple terms?
A cookie is a small note a website leaves in your browser. On later visits to matching pages, the browser sends that note back so the site can recognize your session or preferences.
Where are cookies stored?
Browsers keep cookies in a per-profile cookie jar with metadata such as name, value, domain, path, expiry, and security flags. Developers should treat values as potentially visible to the user and to other software on the device.
What is the difference between a session cookie and a persistent cookie?
A session cookie typically expires when the browsing session ends. A persistent cookie has an Expires or Max-Age value and can survive browser restarts until that lifetime ends or the user clears it.
Can JavaScript always read cookies?
No. Cookies marked HttpOnly are hidden from document.cookie and similar script APIs. Scripts can still often influence other cookies that lack HttpOnly.
Do cookies replace localStorage or sessionStorage?
No. Cookies are automatically attached to matching HTTP requests. Web storage APIs keep data in the page origin without automatic request attachment, which changes both convenience and attack surface.
Are cookies encrypted?
Not by default. The Secure attribute requires HTTPS transport, but the cookie value itself is not encrypted at rest in the browser. Sensitive values still need careful design and short lifetimes.
How should teams use cookies securely?
Prefer minimal sensitive data, set Secure HttpOnly and appropriate SameSite flags, scope Domain and Path tightly, rotate session identifiers, and combine cookies with CSRF defenses where needed.
References
Explore authoritative guidance and frameworks related to cookie.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.