Cookie-uri, localStorage, sessionStorage

De ce ai nevoie de stocare în browser

HTTP e stateless: serverul nu știe că request-ul 2 vine de la același om ca request-ul 1. Iar o pagină, la reload, pornește de la zero. Ca să „ții minte” ceva — login, coș, preferințe, un formular pe jumătate completat — ai nevoie de un loc unde datele supraviețuiesc.

Browserul îți dă 5 astfel de locuri, fiecare cu alt scop.

Tipurile de stocare — comparație

Toate sunt izolate pe origin: a.ro nu poate citi ce a salvat b.ro.

Cookie-uri

Un cookie e un text mic pe care serverul îl setează, iar browserul îl trimite automat înapoi la fiecare request spre același site. De aceea e singurul mod prin care serverul te poate recunoaște.

Set-Cookie: session=abc123; Max-Age=2592000; Path=/; HttpOnly; Secure; SameSite=Lax

Aplicația asta îți setează un cookie vid (httpOnly) — așa îți recunoaște progresul pe server fără cont.

În Next citești cookie-uri cu cookies() din next/headers și le setezi în Server Actions, Route Handlers sau proxy.ts.

localStorage

Stocare cheie → string, permanentă, partajată de toate tab-urile aceluiași site.

localStorage.setItem('theme', 'dark')
localStorage.getItem('theme')                 // 'dark'
localStorage.removeItem('theme')

localStorage.setItem('cart', JSON.stringify(cart))   // obiectele → JSON
const cart = JSON.parse(localStorage.getItem('cart') ?? '[]')

• Doar stringuri — obiectele trec prin JSON.stringify / JSON.parse.
• API sincron: blochează thread-ul; nu salva megabytes la fiecare tastă.
• Când un tab modifică localStorage, celelalte tab-uri primesc evenimentul storage — așa sincronizezi tema între tab-uri.

sessionStorage

Același API ca localStorage, dar datele trăiesc doar cât trăiește tab-ul:

sessionStorage.setItem('checkout-step', '2')
sessionStorage.getItem('checkout-step')       // '2' — doar în tab-ul ăsta

Când e mai bun decât localStorage: un wizard de checkout sau un formular lung pe care îl ai deschis în două tab-uri — fiecare tab își păstrează propriul progres, fără să se calce pe picioare.

IndexedDB

O bază de date în browser: tabele (object stores), indecși, tranzacții, obiecte întregi (nu doar stringuri), fișiere. API-ul e asincron (nu blochează pagina), dar verbos — în practică folosești un wrapper mic:

import { get, set } from 'idb-keyval'
await set('drafts', [{ id: 1, text: '...' }])   // obiecte direct, fără JSON
const drafts = await get('drafts')

Pentru: aplicații offline, cache de date mari, fișiere încărcate de user înainte de upload.

Cache Storage

Păstrează perechi request → response întregi. Îl folosesc service workers ca un site să meargă offline (PWA). Rar îl atingi direct în aplicații obișnuite.

Reguli de siguranță

• Niciodată token-uri de autentificare în localStorage / sessionStorage — orice script de pe pagină (inclusiv unul injectat prin XSS) le poate citi. Sesiunea stă într-un cookie HttpOnly.
• Storage-ul poate arunca eroare (mod privat, spațiu plin, site-data blocat) → try/catch în jurul fiecărei citiri / scrieri.
• Nu există pe server: în Next, citește-l doar în Client Components, după montare (în useEffect sau useSyncExternalStore), altfel ai erori de hidratare.
• Userul îl poate șterge oricând — nu e o bază de date de încredere pentru date importante.

Cum alegi

Pe scurt

• Cookie = singurul care merge automat la server; HttpOnly; Secure; SameSite=Lax pentru sesiuni.
• localStorage = permanent, toate tab-urile; sessionStorage = per tab, până la închidere; ambele doar stringuri, sincrone.
• IndexedDB pentru date mari și offline; niciodată secrete în storage; mereu try/catch.

Surse oficiale

• MDN — Using HTTP cookies
• MDN — Web Storage API
• MDN — Window.sessionStorage
• MDN — IndexedDB API
• MDN — CacheStorage