Wat is localStorage en sessionStorage?

localStorage en sessionStorage zijn twee mechanismen die worden geboden door de Web Storage API, een standaard die in elke moderne browser is ingebouwd. Hiermee kunnen websites sleutel-waardeparen rechtstreeks in de browser van de bezoeker opslaan, zonder dat de server bij elke paginalading betrokken hoeft te worden. Als u ooit op een website de donkere modus hebt ingeschakeld en de volgende dag merkt dat uw voorkeur er nog steeds was, dan heeft de site die keuze waarschijnlijk in localStorage opgeslagen.

Hoe de Web Storage API werkt

De Web Storage API is bewust eenvoudig. U roept localStorage.setItem('sleutel', 'waarde') aan om gegevens te schrijven, localStorage.getItem('sleutel') om te lezen en localStorage.removeItem('sleutel') om te verwijderen. sessionStorage gebruikt exact dezelfde methoden. Beide opslagsystemen accepteren alleen strings, dus objecten worden meestal geserialiseerd met JSON.stringify() voordat ze worden opgeslagen. Er is geen querytaal, geen indexering en geen relationele structuur. Het is een platte sleutel-waarde-opslag ontworpen voor snelle, lichtgewicht lees- en schrijfbewerkingen.

localStorage versus sessionStorage: belangrijke verschillen

• Persistentie: localStorage-gegevens blijven in de browser totdat de gebruiker of de site ze expliciet verwijdert. Er is geen vervaldatum. sessionStorage-gegevens worden daarentegen gewist op het moment dat het browsertabblad wordt gesloten.
• Bereik over tabbladen heen: localStorage wordt gedeeld tussen alle tabbladen en vensters die tot dezelfde origin (protocol + domein + poort) behoren. sessionStorage is geïsoleerd per tabblad. Als u dezelfde pagina in twee tabbladen opent, heeft elk tabblad zijn eigen sessionStorage.
• Opslaglimieten: beide bieden doorgaans 5 tot 10 MB per origin, afhankelijk van de browser. Chrome en Firefox hebben standaard ongeveer 5 MB per origin per opslag. Safari kan strenger zijn, vooral in privémodus, waar het de opslag soms beperkt tot slechts enkele honderden kilobytes.
• Netwerkgedrag: noch localStorage noch sessionStorage worden met HTTP-verzoeken naar de server verzonden. Dit is het fundamentele verschil met cookies, die automatisch aan elke verzoekkoptekst worden gekoppeld.

Wat WordPress-sites doorgaans opslaan

WordPress-plug-ins en thema's gebruiken browseropslag voor een breed scala aan doeleinden. Hier zijn de meest voorkomende:

• Themavoorkeuren: schakelaars voor de donkere modus, zijbalk ingeklapt/uitgeklapt-status, lettergroottekeuzes. Deze worden vrijwel altijd in localStorage opgeslagen, omdat ze het sluiten van een tabblad moeten overleven.
• Winkelwagengegevens: WooCommerce en vergelijkbare plug-ins cachen soms winkelwagenfragmenten in localStorage om extra serveromwegen te vermijden bij het weergeven van de mini-winkelwagen in de koptekst.
• Formulierconcepten: contactformulier-plug-ins kunnen gebruikersinvoer automatisch opslaan in sessionStorage, zodat een gedeeltelijk ingevuld formulier niet verloren gaat als de gebruiker per ongeluk wegnavigeert en vervolgens via de terug-knop terugkeert.
• Cookieconsentkeuzes: sommige consentbanner-plug-ins (zoals Complianz of CookieYes) slaan de consentstatus van de bezoeker op in localStorage in plaats van in een cookie, hoewel het gebruik van een cookie vaker voorkomt.
• Beheer-UI-status: het WordPress-beheerdashboard zelf gebruikt beide opslagmechanismen. Het onthoudt bijvoorbeeld welke metaboxen zijn ingeklapt, welke kolommen zichtbaar zijn in de berichtenlijst en of het beheermenu is ingevouwen.
• Analyse- en trackingbuffers: sommige analysescripts batchen gebeurtenissen in localStorage en sturen ze in groepen naar de server om netwerkverzoeken te verminderen.

Beveiligingsoverwegingen

Web Storage is handig, maar brengt echte beveiligingsafwegingen met zich mee die ontwikkelaars moeten begrijpen.

• XSS-blootstelling: elk JavaScript dat op de pagina draait, kan localStorage en sessionStorage lezen. Als een aanvaller erin slaagt een script te injecteren via een cross-site scripting (XSS)-kwetsbaarheid, kan hij elke opgeslagen waarde extraheren. Cookies kunnen worden beschermd met de HttpOnly-vlag, die JavaScript-toegang volledig blokkeert. Er is geen gelijkwaardige bescherming voor Web Storage.
• Same-origin policy: opslag is gericht op de origin, wat betekent dat https://example.com geen opslag kan lezen van https://other.com. Echter, elk script op dezelfde origin, inclusief externe scripts die u laadt (analytics, advertentienetwerken, chatwidgets), heeft volledige toegang tot dezelfde opslag.
• Geen versleuteling: gegevens worden in platte tekst op schijf opgeslagen. Iedereen met fysieke toegang tot het apparaat, of malware die op het apparaat draait, kan het lezen. Sla nooit wachtwoorden, tokens of andere gevoelige inloggegevens op in Web Storage.
• Geen server-side validatie: aangezien de gegevens alleen in de browser leven, kan een gebruiker of script ze vrijelijk wijzigen. Vertrouw nooit op Web Storage-waarden voor autorisatie of beveiligingsbeslissingen op de server.

GDPR en privacy-implicaties

Onder de GDPR en de ePrivacy-richtlijn worden localStorage en sessionStorage op dezelfde manier behandeld als cookies wat betreft consentvereisten. Het juridische principe is technologie-neutraal: als u informatie opslaat of leest op het apparaat van een gebruiker voor een doel dat niet strikt noodzakelijk is voor de dienst die de gebruiker heeft aangevraagd, hebt u toestemming nodig. Dit betekent dat een WooCommerce-winkelwagen die in localStorage is opgeslagen, waarschijnlijk "strikt noodzakelijk" is en geen toestemming vereist. Maar een analytics-ID die in localStorage is opgeslagen om terugkerende bezoekers te volgen, vereist absoluut wel toestemming. Veel site-eigenaren zien dit over het hoofd, omdat cookieconsenttools zich traditioneel richten op cookies, maar toezichthouders hebben duidelijk gemaakt dat de regels van toepassing zijn op alle client-side opslagtechnologieën.

Web Storage versus cookies: wanneer welke gebruiken

• Gebruik cookies: wanneer de server bij elk verzoek de waarde moet lezen (sessie-ID's, authenticatietokens), wanneer u HttpOnly-bescherming tegen XSS nodig hebt, of wanneer u fijnmazige vervalcontrole nodig hebt.
• Gebruik localStorage: wanneer u client-side voorkeuren moet bewaren of gegevens moet cachen over sessies heen, de gegevens niet naar de server hoeven te reizen en de gegevens niet gevoelig zijn.
• Gebruik sessionStorage: wanneer de gegevens slechts voor de duur van een enkele tabbladsessie moeten leven, zoals voortgang van een formulierwizard, tijdelijke UI-status of eenmalige redirect-tokens.

Prestatievergelijking

Lezen van en schrijven naar Web Storage is synchroon en gebeurt op de hoofdthread. Voor kleine hoeveelheden gegevens is dit snel, meestal onder een milliseconde. Maar als een pagina bij elke interactie grote hoeveelheden gegevens schrijft of leest, kan dit jank veroorzaken. Cookies voegen daarentegen op een andere manier overhead toe: ze vergroten de grootte van elke HTTP-verzoekkoptekst, wat elke netwerkoproep vertraagt. Voor het opslaan van een handvol kleine waarden presteren beide benaderingen goed. Voor grotere datasets (tientallen KB of meer) overweegt u IndexedDB, dat asynchroon is en de hoofdthread niet blokkeert.

Hoe u opslag in DevTools kunt inspecteren

Met elke grote browser kunt u Web Storage inspecteren. Open in Chrome DevTools (F12), ga naar het tabblad Application en zoek "Local Storage" en "Session Storage" in de linkerzijbalk. U kunt elk sleutel-waardepaar zien, waarden handmatig bewerken en items verwijderen. Firefox heeft een vergelijkbaar paneel onder het tabblad Storage. Dit is de eenvoudigste manier om precies te zien wat een WordPress-site in uw browser opslaat en om onverwacht gedrag op te lossen.

Wat InspectWP controleert

InspectWP somt alle localStorage- en sessionStorage-vermeldingen op die door uw WordPress-site tijdens de scan zijn ingesteld. Dit geeft u een duidelijk beeld van wat uw site client-side opslaat, welke plug-ins verantwoordelijk zijn en of bepaalde vermeldingen privacyzorgen onder GDPR- of ePrivacy-regels kunnen oproepen.