Frontend Cookies, Storage, and Privacy in 2026

By /
⏱ 3 min read

The cookie and storage landscape changed a lot between 2020 and 2026. Third-party cookie deprecation hit in stages; SameSite defaults tightened; the privacy regulations multiplied; new APIs (Storage Access, CHIPS) emerged. Senior interviews probe whether you understand the modern picture. This guide is the working state.

The state of third-party cookies in 2026

  • Safari blocked third-party cookies via ITP starting 2017; refined since
  • Firefox blocked via ETP since 2019
  • Chrome’s timeline shifted multiple times; effectively phased out for most third-party use cases by 2026
  • “Cross-site tracking” via cookies is essentially dead
  • Replacement APIs: Storage Access API, CHIPS (partitioned cookies), FedCM, Privacy Sandbox
  • HttpOnly — JS cannot read; protects against XSS theft
  • Secure — HTTPS only
  • SameSite=Strict — never sent cross-origin
  • SameSite=Lax — sent on top-level GET cross-origin (modern default)
  • SameSite=None — sent always; requires Secure
  • Partitioned (CHIPS) — third-party cookie scoped to top-frame site

The first-party storage stack

  • Cookies: small (~4 KB), sent with every request, persisted across tabs
  • localStorage: ~5–10 MB, synchronous, persists indefinitely, scoped to origin
  • sessionStorage: like localStorage but tab-scoped
  • IndexedDB: async, structured, large quotas (typically 50%+ of disk)
  • Cache API (Service Worker): for HTTP responses
  • OPFS (Origin Private File System): file-system-like API; Worker-only

Where to put auth tokens

  • HttpOnly cookies: immune to XSS; CSRF protection needed
  • localStorage: readable by any JS on the page; stolen by XSS
  • In-memory: lost on refresh; pair with refresh-token cookie

Modern best practice for SPAs: refresh token in HttpOnly cookie, access token in memory.

The Storage Access API

Used when an embedded iframe needs access to its own first-party storage from within a third-party context:

  • iframe calls document.requestStorageAccess()
  • User may be prompted to grant access
  • Once granted, iframe can read/write its first-party storage
  • Use case: embedded chat widget, single sign-on iframes

CHIPS — partitioned cookies

  • Third-party cookies that are partitioned by top-level site
  • Set with Partitioned attribute
  • Use case: stateful embeds (chat support, payments) without cross-site tracking
  • Eliminates the cross-site privacy concern

FedCM (Federated Credential Management)

  • Browser-mediated authentication flow
  • Replaces third-party cookies for “Sign in with Google” and similar
  • User sees a browser-native UI; not the IdP’s cookies
  • Adoption: Google supports; Apple is more cautious

The Privacy Sandbox APIs

  • Topics: browser-derived interest categories shared without cross-site tracking
  • Protected Audience (formerly FLEDGE): on-device ad auctions
  • Attribution Reporting: conversion measurement without identifiers
  • Adoption is mixed; Google ships them; Safari and Firefox often do not

Privacy regulations to know

  • GDPR (EU): consent for non-essential cookies; right to access / delete data
  • CCPA / CPRA (California): opt-out of sale; data subject rights
  • UK Age Appropriate Design Code: children’s privacy stricter
  • Brazil LGPD, India DPDP, etc.: increasingly aligned with GDPR
  • State laws in US (Virginia, Colorado, Texas, others) — “patchwork” complexity
  • Required in EU for non-essential cookies
  • Must allow rejection as easily as acceptance
  • Granular categories: necessary / functional / analytics / marketing
  • Respect choice across the session and future visits
  • OneTrust, Cookiebot are common implementations

Global Privacy Control (GPC)

  • HTTP header that signals user opt-out preference
  • Required to be honored by some US state laws (California)
  • Browser can send; sites must respect

IndexedDB in production

  • Async API; do not block the main thread
  • Use a wrapper (Dexie, idb) for ergonomics
  • Store: cached app state, offline queue, large data
  • Browser may evict on storage pressure

The persistent storage permission

  • navigator.storage.persist() requests durability
  • If granted, browser will not evict
  • Use sparingly — UAs may limit per-origin

Cross-origin storage isolation

  • HTTP-level isolation via COOP / COEP
  • Required for SharedArrayBuffer, high-resolution timers
  • Concern for embedded scripts (third-party widgets break)

Common interview questions

  • “Where do you store authentication tokens? Why?”
  • “What are the differences between SameSite=Lax and SameSite=Strict?”
  • “How does the Storage Access API work?”
  • “What is CHIPS and why does it matter?”
  • “How do you comply with GDPR for cookies?”

What separates senior from staff

Senior candidates know storage APIs and basic cookie attributes. Staff candidates discuss the post-third-party-cookie landscape (Storage Access, CHIPS, FedCM, Privacy Sandbox) and the regulatory compliance surface. Principal candidates raise the architectural impact (federated auth strategies, embed strategies, data minimization).

Frequently Asked Questions

Should I worry about Privacy Sandbox?

If you build advertising or analytics products, yes. If you build SaaS, the impact is usually contained to your analytics vendor.

Is localStorage safe for tokens?

No, with caveats. If your app has zero XSS surface (well-built modern stack), the practical risk is low. But the threat model is “any XSS = full token compromise” — preferred to use HttpOnly cookies.

What about the encrypted client database trend?

Apps like Notion encrypt local IndexedDB data with a derived key. Useful for sensitive data; small overhead. Worth knowing but not standard.

Scroll to Top