Cookies are the oldest and most understood browser storage mechanism. Despite being small and seemingly simple, cookies remain foundational to authentication, sessions, and security on the web.
This chapter explains how cookies actually work, why they still matter in modern applications, and how to use them correctly and securely.
What Exactly Is a Cookie?
A cookie is a small piece of data stored by the browser that is automatically sent to the server with HTTP requests that match specific rules.
At its core, a cookie is:
name = value + attributesExample:
sessionID=abc123; HttpOnly; Secure; SameSite=StrictCookies are not just storage – they are part of the HTTP protocol behavior.
How Cookies Work (Request-Response Flow)
- Client sends a request
- Server responds with a
Set-Cookieheader - Browser stores the cookie
- On subsequent requests, browser automatically attaches the cookie
Conceptually:
Client → Request
Server → Set-Cookie
Browser → Store cookie
Browser → Send cookie with future requestsThis automatic behavior is what makes cookies special – and dangerous is misused.
Cookie Scope: When Is a Cookie Sent?
Cookies are not sent everywhere. They are governed by scope rules.
Domain
- A cookie is sent only to matching domains
- Subdomains can be included or excluded
Example:
example.com-> sent toapi.example.comauth.example.com-> not sent toshop.example.com
Path
- Restricts cookies to URL paths
Example:
Path=/adminExpiration:
- Session cookies -> deleted when browser closes
- Persistent cookies -> expire at a fixed time
Cookie Security Attributes
Modern cookies relies heavily on security flags.
HttpOnly
- Prevents JavaScript access
- Protects against XSS token theft
HttpOnlySecure
- Sent only over HTTPS
- Prevents network sniffing
SecureSameSite
Controls cross-site cookie sending.
Strict: never sent cross-siteLax: sent on top-level navigationNone: sent everywhere (requires Secure)
This attribute is a major defense against CSRF attacks.
Cookies and Authentication Sessions
Cookies are the industry standard for session-based authentication.
Typical flow:
- User logs in
- Server creates a session
- Session ID stored in HttpOnly cookie
- Cookie sent automatically with every request
Why this works well:
- Session ID never exposed to JavaScript
- Server maintains full control
- Easy invalidation
Cookies vs Tokens in Local Storage
A common mistake is storing JWTs in localStorage.
Why cookies are safer
- HttpOnly prevents JS access
- Automatically sent
- Protected by SameSite
When cookies are problematic
- Cross-domain APIs
- Third-party contexts
- CORS complexity
Rule of thumb:
If security matters, prefer HttpOnly cookies.
Performance Considerations
Cookies are sent with every matching HTTP request.
Implications:
- Large cookies increase latency
- Too many cookies degrade performance
Best practices:
- Keep cookies minimal
- Store only identifiers, not data
Common Cookie Mistakes
- Storing sensitive data directly
- Missing HttpOnly flag
- Using SameSite=None unnecessarily
- Oversized cookies
- Relying on cookies for client-only state
Most authentication vulnerabilities come from misconfigured cookies, not form cookies themselves.
When Should You Use Cookies?
Cookies are ideal for:
- Authentication sessions
- CSRF tokens
- User identification
Cookies are not ideal for:
- Large data
- Client-only state
- Offline storage
Leave a comment
Your email address will not be published. Required fields are marked *
