Handling cookies is a minefield

Original Article ↗ Hacker News Discussion ↗

HTTP cookies, once a simple way to maintain sessions, have evolved into a fragile, inconsistent mechanism whose real-world behavior often diverges from the specifications. Developers describe subtle incompatibilities between browsers and server libraries, tricky edge cases around allowed characters, domains and paths, and security concerns such as CSRF and exposure of tokens to JavaScript. Many argue that cookies should be used only for minimal, opaque identifiers—or replaced entirely by better-designed storage and authentication mechanisms—yet backwards compatibility and tracking use cases make them very hard to change.

Cookie complexity and evolving standards

  • Commenters note cookies keep accreting features: SameSite, prefixes like __Host-, varying browser support and quirks.
  • Prefixes are widely supported and backward-compatible, but are opt‑in; you can ignore them if your needs are simple.
  • Some think cookies are a “minefield”; others argue if you follow the current spec carefully, it’s manageable.

Parsing differences and real‑world bugs

  • Cookie header parsing diverges between RFCs, browsers, servers, and libraries, making interoperability fragile.
  • Examples: Firefox accepting characters discouraged by the RFC; Safari being far stricter (dropping/ignoring/truncating).
  • Multiple languages/libraries (Go stdlib, Python’s cookie parser, Crystal HTTP client, certain JS libraries) have had subtle cookie bugs.
  • Several people mention production issues caused by quotes, commas, or non‑ASCII characters in cookies.

What to store in cookies (and how)

  • Many argue cookies should carry only small opaque tokens (session IDs), with all real state on the server.
  • JSON in cookies is widely seen as risky: reserved characters, parsing edge cases, header size limits.
  • Recommended mitigations: strict character sets, base64 or base64url encoding (with care to define which), and keeping values short.
  • JWTs are cited as a common workaround, though some feel they’re overused.

Path, domain, and environment pitfalls

  • Cookie “shadowing” (same name, different path/domain) leads to multiple indistinguishable values and hard‑to‑delete cookies.
  • Deleting requires matching the original path/domain exactly; if you don’t know them, you may be stuck.
  • Using Path is called a “code smell” by some, but others defend it for scoping (e.g., login-only cookies, /api‑only auth).
  • Sharing prod/staging/dev on the same registrable domain is described as a serious long‑term mistake due to cross‑env cookie leakage; separate domains/TLDs or carefully structured subdomains are recommended.

Alternatives and “new cookie” ideas

  • Suggestions include a redesigned “NewCookie” mechanism or leaning more on localStorage/sessionStorage plus service workers.
  • Objections: localStorage can’t be HttpOnly and is fully readable by JS; not suitable for secure session tokens.
  • Some propose using the Authorization header and browser‑level auth UIs, but others note this doesn’t map cleanly to today’s multi‑page flows and CSRF protections.

Postel’s law and protocol design

  • Strong disagreement over Postel’s law: some blame “be liberal in what you accept” for today’s messy ecosystems; others say the real failure is senders not being conservative.
  • One view: being too permissive entrenches non‑compliant behavior; another: strictness everywhere makes systems brittle and harder to evolve.
  • A broader idea emerges: HTTP sub‑features (like cookies) should have explicit, negotiable versions to allow evolution without breaking old clients.