DEV Community

Ume
Ume

Posted on

Understanding Browser Cookie Behavior (Part 2)

#webdev #security #cookie #architecture

Understanding Browser Cookie Behavior (Part 2)

In Part 1, I covered what cookies are and why they exist.

In this second article, I’ll focus on a topic that often causes confusion in real-world development:

Where browsers store cookies, and when they actually send them.

While implementing cookie issuance logic myself, I repeatedly ran into issues such as:

  • Cookies not being sent as expected
  • Cookies not disappearing (or mysteriously remaining)
  • Behavior changing due to SameSite differences
  • Different behavior across browsers

This article organizes those common points of confusion.

Where Are Cookies Stored in the Browser?

Cookies are automatically stored and managed by the browser.

The exact storage location differs by browser, but the concept is the same.

Chrome (Chromium-based browsers)

  • 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

Firefox

  • Stored in cookies.sqlite
  • Accessible via DevTools under the Storage tab

In all cases, developers never interact with these files directly—the browser handles everything.

When Are Cookies Sent?

Cookies are only sent when all required conditions are satisfied.

If even one condition fails, the browser will not include the cookie.

  1. The request domain matches the Domain attribute
  2. The request path matches the Path attribute
  3. If Secure is set, the request uses HTTPS
  4. The SameSite condition is satisfied
  5. The cookie has not expired

If any of these are misconfigured, cookies may silently fail to be sent.

Cookie Attributes and Their Behavior

1. Domain

Example:

Set-Cookie: token=abc; Domain=example.com;

This cookie will be sent to:

  • example.com
  • www.example.com

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,

meaning it is sent only to the issuing domain and not to subdomains.

2. Path

Example:

Set-Cookie: token=abc; Path=/app;

The cookie is sent only for requests under /app.

Using Path=/ causes the cookie to be sent with all requests to the domain.

3. Secure

Cookies with the Secure attribute are only sent over HTTPS.

Examples:

  • https://example.com → sent
  • http://localhost → not sent

This is a common pitfall in local development.

I personally lost time debugging issues caused by not fully understanding this behavior.

4. HttpOnly

Cookies with HttpOnly cannot be accessed from JavaScript.

Because of this:

  • HttpOnly cookies cannot be set via JavaScript
  • They must be set using Set-Cookie on the server

Example:

document.cookie

→ HttpOnly cookies will not appear

This attribute is critical for security, especially as a defense against XSS.

5. SameSite

One of the most impactful cookie attributes today.

  • SameSite=Lax (default)
  • SameSite=None (allows cross-site requests, but requires Secure)
  • SameSite=Strict (sent only for same-site requests)

Authentication flows and integrations with external services often fail because cookies are blocked by SameSite rules.

Differences in Browser Behavior

Due to historical reasons and security policies, cookie behavior differs slightly between browsers.

Chrome

  • Strict adherence to SameSite specifications
  • SameSite=None requires Secure

Safari (including iOS)

  • Strongly affected by ITP (Intelligent Tracking Prevention)
  • 3rd-party cookies are deleted very quickly
  • Even 1st-party cookies may be deleted if the user does not revisit within 7 days

Many cases of “login sessions suddenly expiring” or unstable external integrations are caused by ITP.

Firefox

  • Generally close to the specification
  • Behavior may differ in private browsing mode

Because of these differences, testing across multiple browsers is essential.

Common Reasons Cookies “Remain” or “Disappear”

Typical causes encountered in development include:

  • 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

Since I previously paid little attention to browser-level behavior, it took time to determine whether issues were caused by my implementation or by browser rules.

Cookies often fail due to overlapping conditions, so debugging requires checking them one by one.

Summary

  • Cookies are stored internally in the browser (often using SQLite)
  • Cookie transmission depends on Domain, Path, Secure, SameSite, and HttpOnly
  • 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

Part 3 Preview

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

Original Japanese article:

https://zenn.dev/bysontech/articles/68c9e472adb403

Top comments (0)