# Frontend Cookies, Storage, and Privacy in 2026

Source: https://www.techinterview.org/post/3233475403/frontend-cookies-storage-privacy-2026/
Updated: 2026-05-06 · techinterview.org

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

## Cookie attributes that matter

- `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

## The cookie consent banner

- 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.