Understanding Browser Cookie Behavior (Part 2)
Source: Dev.to
Introduction
In Part 1, I covered what cookies are and why they exist.
In this second article, I focus on a topic that often causes confusion in real‑world development: where browsers store cookies and when they actually send them.
Where Browsers Store Cookies
Cookies are automatically stored and managed by the browser. The exact storage location differs by browser, but the concept is the same.
- General: Stored in a local SQLite database (e.g., a Cookies file). Viewable via DevTools → Application > Cookies.
- Safari (macOS / iOS): Managed internally by WebKit, often not accessible as user‑visible files. Stored in
cookies.sqliteand viewable via DevTools under the Storage tab.
In all cases, developers never interact with these files directly—the browser handles everything.
When Cookies Are Sent
A cookie is sent only when all required conditions are satisfied. If even one condition fails, the browser will not include the cookie.
| Condition | Requirement |
|---|---|
| Domain | The request domain matches the cookie’s Domain attribute |
| Path | The request path matches the cookie’s Path attribute |
| Secure | If the Secure flag is set, the request uses HTTPS |
| SameSite | The SameSite condition is satisfied |
| Expiry | The cookie has not expired |
Domain Attribute
Set-Cookie: token=abc; Domain=example.com;- Sent to
example.com,www.example.com, etc. - If you specify
Domain=www.example.com, the cookie is only sent to that exact host. - If the Domain attribute is omitted, the cookie becomes a host‑only cookie, sent only to the issuing domain (no subdomains).
Path Attribute
Set-Cookie: token=abc; Path=/app;- Sent only for requests under
/app. - Using
Path=/causes the cookie to be sent with all requests to the domain.
Secure Attribute
Cookies with the Secure flag are sent only over HTTPS.
https://example.com → sent
http://localhost → not sentThis is a common pitfall in local development.
HttpOnly Attribute
Cookies with HttpOnly cannot be accessed from JavaScript.
document.cookie; // HttpOnly cookies will not appear- HttpOnly cookies must be set using the
Set-Cookieheader on the server. - This attribute is critical for security, especially as a defense against XSS.
SameSite Attribute
| Value | Behavior |
|---|---|
Lax (default) | Sent on same‑site requests and top‑level navigation GETs |
None | Allows cross‑site requests but requires the Secure flag |
Strict | Sent only for same‑site requests |
Authentication flows and integrations with external services often fail because cookies are blocked by SameSite rules. Modern browsers enforce these rules strictly; SameSite=None must be accompanied by Secure.
Safari’s Intelligent Tracking Prevention (ITP)
- Strongly affects third‑party cookies: they are deleted very quickly.
- Even first‑party cookies may be deleted if the user does not revisit within 7 days.
- Leads to “login sessions suddenly expiring” or unstable external integrations.
- Generally follows the specification but may differ in private‑browsing mode.
Typical Causes Encountered in Development
- Cookies with different Path values existing simultaneously.
- Multiple cookies created due to different Domain settings.
- Cookies blocked by SameSite in cross‑site requests.
- Secure cookies not sent over HTTP in local environments.
- HttpOnly cookies not visible in JavaScript, causing confusion.
- Automatic deletion by Safari’s ITP.
Summary
- Cookies are stored internally in the browser (often using SQLite).
- Transmission depends on Domain, Path, Secure, SameSite, and HttpOnly attributes.
- SameSite is a critical modern attribute that must be understood.
- Safari’s ITP has a strong impact on cookie behavior.
- Issues with cookies persisting or disappearing are usually due to configuration or browser differences.
What’s Next
In the next article, I’ll walk through real code examples, including:
- Issuing cookies on the server side (Java)
- Manipulating cookies with JavaScript
- Common pitfalls in local development