Kort svar: SessionStorage og localStorage er begge browserbaserede Web Storage API'er, der lader hjemmesider gemme data på en brugers enhed, men de adskiller sig kritisk i vedholdenhed og omfang. localStorage bevarer data på ubestemt tid på tværs af sessioner og faner, mens sessionStorage sletter data, når browserfanen lukkes. Fra et privatlivssynspunkt indebærer localStorage en væsentligt højere risiko, fordi data forbliver uden udløb, hvilket gør det til et mere attraktivt mål for sporing, fingeraftryk og lovgivningsmæssig kontrol under rammer som GDPR.
Nøglepunkter
- localStorage forbliver på ubestemt tid, indtil det udtrykkeligt ryddes; sessionStorage slettes, når fanen eller vinduet lukkes.
- Begge lagertyper er sårbare over for cross-site scripting (XSS) angreb og tilbyder ingen indbygget kryptering.
- Hverken localStorage- eller sessionStorage-data overføres automatisk til serveren, i modsætning til cookies, men begge er fuldt læsbare af enhver JavaScript, der kører på samme oprindelse.
- Tredjeparts-scripts, der er indlæst på en side, kan få adgang til localStorage-data, hvis de kører inden for samme oprindelseskontekst.
- Under GDPR er lagring af ikke-essentielle data i localStorage uden brugerens samtykke en overtrædelse af overholdelse, ligesom at placere sporingscookies.
- Følsomme data som autentificeringstokens, adgangskoder og personligt identificerbare oplysninger (PII) bør aldrig gemmes i nogen af mekanismerne uden yderligere sikkerhedslag.
- Privat/inkognito-browsing begrænser localStorage-vedholdenhed, men eliminerer ikke sessionStorage-risici inden for en session.
- Udviklere bør foretrække sessionStorage til midlertidig tilstand, server-side sessioner eller HttpOnly-cookies til autentificering og en Consent Management Platform som Biscotti CMP til styring af lagersamtykke.
Hvad er forskellen mellem SessionStorage og LocalStorage?
SessionStorage og localStorage er begge en del af HTML5 Web Storage API'en, men de tjener forskellige formål defineret af deres vedholdenhed og faneblads-scope-adfærd.
localStorage gemmer nøgle-værdi-par uden udløbsdato. Data overlever browsergenstarter, systemgenstarter og ubestemte perioder med inaktivitet, indtil brugeren eller applikationen udtrykkeligt fjerner dem. Det deles på tværs af alle faner og vinduer, der opererer under samme oprindelse (protokol + domæne + port). [1][5]
sessionStorage gemmer kun data i løbet af sidens session. Når brugeren lukker fanen eller vinduet, er dataene væk. Kritisk er, at hver fane opretholder sin egen isolerede sessionStorage; åbning af den samme URL i en anden fane deler ikke den første fanes sessionStorage-data. [1]
| Funktion | localStorage | sessionStorage |
|---|---|---|
| Vedholdenhed | Ubestemt | Kun fane/vindues levetid |
| Delt på tværs af faner | Ja (samme oprindelse) | Nej (isolering pr. fane) |
| Overlever sidegenindlæsning | Ja | Ja |
| Overlever fanebladslukning | Ja | Nej |
| Lagerkapacitet | ~5-10 MB pr. oprindelse | ~5-10 MB pr. oprindelse |
| Serveroverførsel | Nej | Nej |
| HttpOnly-beskyttelse | Ikke tilgængelig | Ikke tilgængelig |
Begge API'er overholder same-origin-politikken, så en side på https://example.com kan ikke læse lager, der er indstillet af https://otherdomain.com. [4]
Har localStorage privatlivsrisici sammenlignet med sessionStorage?
Ja, localStorage indebærer meningsfuldt højere privatlivsrisici end sessionStorage, primært på grund af dets ubestemte vedholdenhed og tilgængelighed på tværs af faner.
Data skrevet til localStorage kan akkumuleres over måneder eller år uden brugerens viden. Annoncører og analyseleverandører har historisk brugt localStorage som en "super-cookie", en sporingsidentifikator, der overlever sletning af cookies, fordi de fleste brugere ikke tænker på at rydde browserlager manuelt. sessionStorage derimod selvdestruerer ved fanebladslukning, hvilket gør det til en langt mindre nyttig sporingsvektor.
Nøglefaktorer for privatlivsrisiko, der er unikke for localStorage:
- Vedvarende sporingsidentifikatorer: Et unikt ID gemt i localStorage kan spore en bruger på tværs af flere besøg uden nogen server-side cookie.
- Datalækage på tværs af faner: Ethvert script, der kører i en fane af samme oprindelse, kan læse alle localStorage-data.
- Udsendelse af lagerhændelser: Ændringer i localStorage udløser en
storage-hændelse i andre åbne faner fra samme oprindelse, hvilket muliggør datasynkronisering på tværs af faner, som brugere ikke kan observere. [5] - Ingen automatisk udløb: I modsætning til cookies, som understøtter
Max-AgeogExpiresattributter, har localStorage ingen TTL-mekanisme.
Kan hjemmesider spore brugere ved hjælp af localStorage og sessionStorage?
Hjemmesider kan og bruger localStorage til vedvarende sporing. sessionStorage er mindre nyttigt til sporing, men udgør stadig overvågningsrisici inden for sessionen.
En enkelt JavaScript-linje, localStorage.setItem('uid', 'abc123'), opretter en vedvarende identifikator, der overlever sletning af cookies. Denne teknik, undertiden kaldet "evercookie" eller storage-baseret respawning, er blevet dokumenteret i privatlivsforskning og er grunden til, at regulatorer i stigende grad behandler localStorage under de samme samtykkeregler som cookies.
sessionStorage kan spore adfærd inden for en enkelt session (sideflow, formularinput, navigationsmønstre), men disse data forsvinder, når fanen lukkes, hvilket begrænser dens anvendelighed til langsigtet profilering.
Hvor længe forbliver data i SessionStorage vs. LocalStorage?
localStorage-data forbliver, indtil de udtrykkeligt slettes, enten ved at brugeren rydder browserlager, hjemmesiden kalder localStorage.removeItem() eller localStorage.clear(), eller browseren håndhæver lagerkvoter. [2]
sessionStorage-data slettes automatisk, når fanen eller vinduet, der oprettede dem, lukkes. De overlever sidegenindlæsninger inden for samme fane, men overføres ikke til nye faner, selvom brugeren duplikerer fanen i nogle browsere. [1]
Praktisk implikation: Hvis en udvikler gemmer et sessionstoken i localStorage i stedet for sessionStorage, forbliver dette token på enheden, efter at brugeren logger ud, medmindre applikationen udtrykkeligt fjerner det. Dette er en almindelig og betydningsfuld fejl.
Er SessionStorage mere privat end localStorage?
For de fleste privatlivs-brugsscenarier, ja, er sessionStorage det mere privatlivsrespekterende valg. Dens automatiske sletning ved fanebladslukning betyder, at data ikke forbliver, hvilket reducerer eksponering fra enhedsdeling, stjålne enheder eller retsmedicinsk analyse.
sessionStorage er dog ikke i sig selv "privat". Inden for en aktiv session er det lige så sårbart over for XSS-angreb som localStorage. Ethvert injiceret script kan kalde sessionStorage.getItem() og udfiltrere data i realtid. [3]
Vælg sessionStorage, hvis: data kun er nødvendige for den aktuelle brugerinteraktion (f.eks. flertrins formularstatus, engangs-navigations-tokens).
Vælg localStorage, hvis: data virkelig skal bevares på tværs af sessioner (f.eks. brugergrænsefladepræferencer, ikke-følsomme indstillinger), og sørg for, at det ikke indeholder noget personligt identificerbart.
Hvilke personlige data bør aldrig gemmes i localStorage?
Følgende kategorier af data bør aldrig gemmes i localStorage (og bør håndteres med ekstrem forsigtighed selv i sessionStorage): [3]
- Autentificeringstokens (JWT'er, OAuth-tokens, sessions-ID'er)
- Adgangskoder eller adgangskode-hashes
- Kreditkort- eller betalingsoplysninger
- Statsudstedte ID-numre eller CPR-numre
- Fulde navne kombineret med e-mailadresser eller telefonnumre
- Medicinske eller sundhedsjournaler
- Enhver data klassificeret som "særlig kategori" under GDPR (biometriske data, sundhedsdata, politiske holdninger)
Data gemt i både localStorage og sessionStorage er ukrypterede som standard. Enhver med fysisk adgang til enheden, eller ethvert script, der er i stand til at udføre på siden, kan læse det i klartekst. [3]
Kan tredjeparts-scripts få adgang til localStorage-data?
Tredjeparts-scripts kan få adgang til localStorage-data, hvis de indlæses og udføres inden for samme oprindelse som værtssiden. Dette er en kritisk og ofte undervurderet risiko.
Når en hjemmeside indlejrer et tredjeparts analyse- eller annoncescript via et <script>-tag, kører dette script i værtssidens oprindelseskontekst. Det kan frit læse og skrive til sidens localStorage. Same-origin-politikken beskytter ikke mod scripts, der bevidst eller utilsigtet er inkluderet på siden. [4]
Hvad dette betyder i praksis: Hvis et websted gemmer en brugeridentifikator i localStorage og også indlæser et tredjeparts annoncescript, kan dette annoncescript læse identifikator og knytte det til adfærdsdata på tværs af websteder, uden brugerens viden eller samtykke.
Dette er en af grundene til, at Consent Management Platforms er vigtige. Biscotti CMP gør det muligt for hjemmesider at administrere og dokumentere brugerens samtykke til lageroperationer, herunder localStorage-baseret sporing, hvilket hjælper websteder med at opfylde deres forpligtelser under GDPR og lignende rammer.
Hvad er GDPR-implikationerne ved brug af localStorage?
Under GDPR kræver enhver lagring af personlige data eller sporingsidentifikatorer, uanset den tekniske mekanisme, et lovligt grundlag. For ikke-essentiel sporing via localStorage er dette grundlag næsten altid udtrykkeligt brugersamtykke. [2]
Det Europæiske Databeskyttelsesråd har bekræftet, at localStorage, der bruges til analyse, annoncering eller brugerprofilering, falder ind under de samme samtykkekrav som cookies. Hjemmesider, der placerer sporingsidentifikatorer i localStorage uden forudgående samtykke, står over for den samme håndhævelseseksponering som dem, der bruger cookies uden samtykke.
Overholdelses-tjekliste for localStorage under GDPR:
- Gennemgå alle localStorage-nøgler skrevet af første- og tredjeparts-scripts.
- Klassificer hver nøgle: er den strengt nødvendig for tjenesten, eller bruges den til analyse/annoncering?
- For ikke-essentiel lagring skal skriveoperationen sikres bag dokumenteret brugersamtykke.
- Giv brugerne en klar mekanisme til at trække samtykke tilbage og udløse sletning af lagring.
- Dokumenter dataansvarliges legitime interesse eller samtykkeregister.
En korrekt konfigureret Consent Management Platform som Biscotti CMP kan automatisere meget af denne samtykkelivscyklus.
Kan localStorage tilgås på tværs af forskellige hjemmesider?
Nej. localStorage er strengt begrænset til den oprindelse (protokol + domæne + portkombination), der oprettede den. Et script på https://siteA.com kan ikke læse localStorage-data, der er indstillet af https://siteB.com. [4]
Denne beskyttelse har dog grænser. Hvis en enkelt annonce- eller analyseudbyder indlæser sine scripts på både siteA.com og siteB.com, skriver hver instans til det respektive websteds localStorage uafhængigt. Udbyderen korrelerer derefter dataene server-side, hvilket effektivt opnår sporing på tværs af websteder uden at overtræde same-origin-politikken.
Hvordan påvirker inkognitotilstand og privat browsing localStorage?
Privat/inkognito-browsing opretter en midlertidig lagerpartition, der slettes, når det private vindue lukkes. localStorage, der er skrevet under en inkognito-session, forbliver ikke i den primære browserprofil og er ikke tilgængelig for almindelige browservinduer.
sessionStorage opfører sig på samme måde i inkognito som i almindelig browsing: det slettes, når fanen lukkes.
Vigtige forbehold:
- Inden for en aktiv inkognito-session er localStorage stadig læsbar af alle scripts, der kører i den sessions same-origin-kontekst.
- Inkognitotilstand forhindrer ikke realtids XSS-baseret dataeksfiltrering.
- Nogle browsere synkroniserer localStorage på tværs af enheder, hvis brugeren er logget ind på browsersynkronisering, en adfærd, der kan flytte "lokale" data til cloud-infrastruktur.
Hvordan rydder jeg SessionStorage og localStorage for privatlivets fred?
Rydning af browserlager er ligetil, men kræver bevidst handling, da browsere ikke gør det automatisk for localStorage.
Rydning på browserniveau:
- Chrome: Indstillinger > Privatliv og sikkerhed > Ryd browserdata > Cachelagrede billeder og filer + Webstedsdata
- Firefox: Indstillinger > Privatliv og sikkerhed > Cookies og webstedsdata > Ryd data
- Safari: Indstillinger > Privatliv > Administrer webstedsdata
Programmatisk rydning (for udviklere):
localStorage.clear()fjerner alle nøgler for oprindelsen.sessionStorage.clear()fjerner alle nøgler for den aktuelle fane-session.localStorage.removeItem('keyName')fjerner en specifik nøgle.
For slutbrugere, der er bekymrede for sporing: rydning af "webstedsdata" eller "cookies og lager" i browserindstillinger fjerner både localStorage- og sessionStorage-indhold for alle websteder. Browserudvidelser designet til privatliv kan automatisere dette på et per-websted eller per-session basis.
Hvad er almindelige privatlivsfejl, udviklere begår med web storage?
De mest betydningsfulde fejl har en fælles rod: at behandle klient-side lagring, som om det var en sikker server-side database.
- Lagring af JWT'er i localStorage: Autentificeringstokens gemt i localStorage er tilgængelige for ethvert script på siden. En enkelt XSS-sårbarhed afslører hver brugers token. Brug HttpOnly-cookies til autentificeringstokens i stedet.
- Ingen udløbslogik: localStorage har ingen TTL. Udviklere, der gemmer data uden at bygge udløbslogik, efterlader forældede, følsomme data på enheder på ubestemt tid.
- Antagelse af, at same-origin betyder sikkert: Same-origin-politikken blokerer eksterne websteder, ikke ondsindede scripts indlæst fra samme websted (XSS, kompromitterede tredjepartsbiblioteker).
- Ignorering af tredjeparts-scriptadgang: Indlejring af analyse- eller annoncescripts uden at revidere, hvad de læser fra localStorage.
- Ingen samtykkeport for sporingslagring: Skrivning af analyseidentifikatorer til localStorage, før brugerens samtykke er indhentet, en direkte GDPR-overtrædelse. [2]
- Lagring af redundante PII: Cachelagring af API-svar, der inkluderer fulde brugerprofiler i localStorage "for ydeevne" uden at overveje eksponeringsfladen.
Er IndexedDB mere privat end localStorage?
IndexedDB er ikke i sig selv mere privat end localStorage. Begge er underlagt same-origin-politikken, begge er tilgængelige for JavaScript, der kører på siden, og begge er sårbare over for XSS-angreb.
IndexedDB tilbyder større lagerkapacitet og understøtter strukturerede data og binære blobs, hvilket gør det velegnet til komplekse offline-applikationer. Men fra et privatlivs- og sikkerhedssynspunkt er risiciene sammenlignelige. Data gemt i IndexedDB er også ukrypterede som standard, og de forbliver på ubestemt tid, medmindre de udtrykkeligt slettes.
Valget mellem IndexedDB og localStorage bør drives af datakompleksitet og volumenkrav, ikke privatlivsantagelser. Ingen af dem er passende til følsomme personlige data uden kryptering på applikationsniveau og strenge adgangskontroller.
Konklusion
Debatten om SessionStorage vs. LocalStorage: Konsekvenser for Privatlivets Fred ved Web Storage API'er er ikke blot en teknisk fodnote; den har direkte konsekvenser for brugerens privatliv, overholdelse af lovgivning og applikationssikkerhed. localStorage's ubestemte vedholdenhed og tilgængelighed på tværs af faner gør det til en højrisiko-lagringsmekanisme, når det misbruges, mens sessionStorage's automatiske sletning ved fanebladslukning gør det til det mere forsvarlige valg for midlertidig tilstand.
Handlingsorienterede næste skridt for udviklere og webstedsejere i 2026:
- Gennemgå al localStorage- og sessionStorage-brug på tværs af første- og tredjeparts-scripts ved hjælp af browserens DevTools (Applikationsfane).
- Fjern straks alle autentificeringstokens, PII eller følsomme identifikatorer fra klient-side lagring.
- Erstat localStorage-baseret auth token-lagring med HttpOnly, Secure cookies, der administreres server-side.
- Implementer en samtykkestyrings-workflow ved hjælp af en platform som Biscotti CMP for at sikre ikke-essentielle localStorage-skrivninger bag dokumenteret brugersamtykke.
- Indbyg udløbslogik i alle localStorage-data, der skal bevares, og håndhæv oprydning ved logud.
- Udfør en tredjeparts-script-revision for at forstå, hvilken ekstern kode der kan læse fra din oprindelses lager.
- Træn udviklingsteams i XSS-forebyggelse som den primære angrebsvektor mod begge lagertyper.
Web storage API'er er kraftfulde værktøjer. Brugt uden privatlivsdisciplin bliver de ansvarsvektorer. Brugt med bevidst afgrænsning, samtykkestyring og sikkerhedshygiejne tjener de deres tilsigtede formål uden at kompromittere de brugere, der stoler på din applikation.
FAQ
Q: Hvad er den største forskel mellem sessionStorage og localStorage? localStorage bevarer data på ubestemt tid på tværs af sessioner og deles på tværs af alle faner af samme oprindelse. sessionStorage gemmer kun data i løbet af den aktuelle fanes levetid og slettes automatisk, når fanen lukkes.
Q: Kan localStorage bruges til at spore brugere uden cookies? Ja. En unik identifikator gemt i localStorage overlever sletning af cookies og kan bruges til at spore brugere på tværs af flere besøg på samme websted, fungerende som en vedvarende sporingsmekanisme.
Q: Er sessionStorage sikkert til opbevaring af adgangskoder? Nej. sessionStorage er ikke krypteret og er tilgængeligt for enhver JavaScript, der kører på siden, herunder injicerede ondsindede scripts. Adgangskoder bør aldrig gemmes i nogen klient-side lagringsmekanisme.
Q: Gælder GDPR for localStorage? Ja. Under GDPR er lagring af sporingsidentifikatorer eller personlige data i localStorage uden et lovligt grundlag, typisk udtrykkeligt brugersamtykke til ikke-essentielle formål, en overtrædelse af overholdelse svarende til brug af cookies uden samtykke.
Q: Kan tredjeparts-scripts læse mine localStorage-data?
Ja, hvis disse scripts indlæses og udføres inden for samme oprindelse. Tredjeparts analyse- eller annoncescripts, der er indlejret via <script>-tags, kører i værtssidens oprindelseskontekst og kan læse alle localStorage-data for den oprindelse.
Q: Rydder sletning af cookies også localStorage? Ikke altid. I de fleste browsere rydder sletning af "cookies" alene ikke localStorage. Brugere skal specifikt rydde "webstedsdata" eller "cookies og andre webstedsdata" for at fjerne localStorage-indhold.
Q: Er inkognitotilstand sikker mod localStorage-sporing? Inkognitotilstand forhindrer localStorage-data i at forblive, efter at det private vindue lukkes, men inden for en aktiv inkognito-session er localStorage stadig læsbar af alle scripts på siden.
Q: Hvad skal jeg bruge i stedet for localStorage til autentificeringstokens? Brug HttpOnly, Secure, SameSite cookies, der administreres server-side. Disse cookies er utilgængelige for JavaScript, hvilket eliminerer risikoen for XSS-baseret token-tyveri, som localStorage indebærer.
Q: Er IndexedDB mere sikkert end localStorage? Nej. IndexedDB er underlagt de samme XSS-sårbarheder og same-origin-politik som localStorage. Det tilbyder større kapacitet og understøttelse af datastruktur, men ingen yderligere privatlivs- eller sikkerhedsgarantier.
Q: Hvor meget data kan localStorage og sessionStorage indeholde? De fleste moderne browsere tildeler cirka 5 til 10 MB lagerplads pr. oprindelse for hver lagertype, betydeligt mere end den typiske 4 KB grænse for cookies. [2]
Referencer
[1] Sessionstorage - https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage?utm_source=openai
[2] What Is Localstorage Sessionstorage - https://inspectwp.com/en/knowledge-base/what-is-localstorage-sessionstorage?utm_source=openai
[3] Html5 Web Storage Security Risks Safeguarding Localstorage And Sessionstorage - https://www.dopethemes.com/html5-web-storage-security-risks-safeguarding-localstorage-and-sessionstorage/?utm_source=openai
[4] Localstorage - https://javascript.info/localstorage?utm_source=openai
[5] Localstorage Sessionstorage - https://www.w3docs.com/learn-javascript/localstorage-sessionstorage?utm_source=openai
[6] Cookies Vs Localstorage Vs Sessionstorage What Each One Exactly Means - https://www.interserver.net/tips/kb/cookies-vs-localstorage-vs-sessionstorage-what-each-one-exactly-means/?utm_source=openai