The Name Tag Analogy
At a conference:
- First day: You get a name tag
- You wear it all day
- Staff recognize you
- Next day: Same name tag
Cookies are name tags for your browser. Websites give you one, your browser wears it on each visit.
What Are Cookies?
Cookies = Small data stored in your browser
Sent by server → Stored by browser → Sent back with matching requests
Size: Typically a few kilobytes per cookie (limits vary by browser)
Format: name=value pairs
How Cookies Work
Setting a Cookie
Server response:
Set-Cookie: session=abc123; Path=/
Browser stores:
{ name: "session", value: "abc123", domain: "example.com" }
Sending Cookies
Requests to example.com (that match the cookie's Domain/Path rules):
Cookie: session=abc123
Automatic! Browser handles it.
The Flow
1. You visit website
2. Server sends Set-Cookie header
3. Browser stores cookie
4. Browser sends cookie with every request
5. Server recognizes you
Cookie Attributes
Essential Attributes
name=value
The actual data stored
Domain
Which domain can access (example.com)
Path
Which paths get the cookie (/admin)
Expires / Max-Age
When cookie dies
No expiry = Session cookie (deleted when the browser-defined "session" ends; session restore can keep them)
Security Attributes
HTTPS-only attribute
Sent only over HTTPS (browsers generally won't send it over plain HTTP)
HttpOnly
JavaScript can't access
Helps prevent XSS from stealing the cookie value (but doesn't prevent XSS itself)
SameSite
Controls cross-site sending
Strict, Lax, or None
Types of Cookies
Session Cookies
No expiration date.
Deleted when browser closes.
Good for:
- Login sessions (during visit)
- Shopping cart (temporary)
Persistent Cookies
Has expiration date.
Survives browser close.
Good for:
- "Remember me"
- Preferences
- Analytics
First-Party Cookies
Set by the website you're visiting.
example.com sets example.com cookie.
Used for: Sessions, preferences.
Third-Party Cookies
Set by other domains (ads, trackers).
analytics.com cookie on example.com.
Used for: Tracking, advertising.
Many browsers restrict third-party cookies for privacy, and the ecosystem has been shifting toward alternatives.
Common Uses
Authentication
Login → Server creates session → Sends session cookie
Each request → Cookie sent → Server knows who you are
Logout → Cookie deleted
Preferences
Dark mode selection → Stored in cookie
Next visit → Cookie read → Dark mode applied
Shopping Cart
Add item → Stored in cookie or session
Navigate → Cart persists
Checkout → Items still there
Analytics
Unique ID in cookie.
Track across pages and visits.
Build user behavior profile.
Security Considerations
XSS and Cookies
An XSS attack can steal cookies (or perform actions as the user), especially if cookies are readable by JavaScript.
JavaScript: document.cookie → All non-HttpOnly cookies
Protection:
Set HttpOnly flag
Script can't access
CSRF and Cookies
Evil site tricks your browser.
Your browser sends your cookies.
Action performed as you!
Protection:
SameSite=Strict or Lax
CSRF tokens
HTTPS-Only Attribute
This attribute tells the browser to only send the cookie over HTTPS.
It helps reduce interception risk on the network.
SameSite Explained
SameSite=Strict
Typically sent on same-site requests.
Generally not sent on cross-site requests.
SameSite=Lax
Sent on top-level navigation (clicking link).
Not sent on cross-site ajax/images.
Often treated as the default when SameSite isn't specified (browser behavior varies).
SameSite=None
Sent everywhere.
Requires the HTTPS-only attribute.
For legitimate cross-site (embedded content).
Cookies vs Other Storage
| Feature | Cookies | JS-managed storage (in-browser) |
|---|---|---|
| Size | Limited (varies) | Often larger (varies) |
| Sent to server | Yes (automatic) | No |
| Expiry | Configurable | Depends on mechanism |
| Access | Sent by the browser | Readable by JavaScript |
Privacy and Regulations
GDPR, CCPA
In many jurisdictions, sites must provide notices and/or get consent for some non-essential cookies (especially tracking/advertising). Requirements vary by region and cookie type.
Third-Party Cookie Restrictions
Many browsers restrict third-party cookies or have been moving in that direction.
The advertising/analytics ecosystem has been adapting with alternative approaches.
Practical Tips
âś“ Use HttpOnly for sensitive cookies
âś“ Use the HTTPS-only cookie attribute when serving over HTTPS
âś“ Set SameSite appropriately
âś“ Set reasonable expiration
âś“ Don't store sensitive data
âś“ Minimal cookie usage
Common Mistakes
1. Storing Sensitive Data
Don't store passwords in cookies!
Store session ID, look up on server.
2. Missing Security Flags
No HttpOnly → XSS can steal
No HTTPS-only attribute → higher risk on insecure networks
No SameSite → higher CSRF risk in some setups
3. Too Long Expiry
Cookie lasts a very long time?
Security risk. Privacy concern.
Use reasonable timeframes.
FAQ
Q: Why do websites ask about cookies?
Depending on the region and cookie type, consent can be required for tracking/analytics cookies (e.g., GDPR/ePrivacy-style rules). Check your local requirements.
Q: Can I see my cookies?
Yes! Browser DevTools → Application → Cookies.
Q: Are cookies dangerous?
Cookies themselves are not. Misuse (tracking, insecure storage) can be.
Q: What's replacing third-party cookies?
Various approaches exist (first-party data, server-side tracking, privacy-preserving APIs, and contextual methods). The ecosystem continues to evolve.
Summary
Cookies are small pieces of data stored by your browser and sent to the server with each request.
Key Takeaways:
- Server sets, browser stores and sends
- Session vs persistent cookies
- Security flags: HttpOnly, HTTPS-only, SameSite
- Used for auth, preferences, tracking
- Third-party cookies being phased out
- Privacy regulations require consent
Cookies keep the web functional but require careful handling!
Related Concepts
Leave a Comment
Comments (0)
Be the first to comment on this concept.
Comments are approved automatically.