Ātrā atbilde: SessionStorage un localStorage ir abas pārlūkprogrammas balstītas tīmekļa krātuves API, kas ļauj vietnēm glabāt datus lietotāja ierīcē, taču tās kritiski atšķiras pastāvības un apjoma ziņā. localStorage saglabā datus neierobežoti starp sesijām un cilnēm, savukārt sessionStorage dzēš datus, kad pārlūkprogrammas cilne tiek aizvērta. No privātuma viedokļa localStorage rada ievērojami augstāku risku, jo dati paliek bez derīguma termiņa, padarot to par pievilcīgāku mērķi izsekošanai, pirkstu nospiedumu iegūšanai un regulatīvai uzraudzībai saskaņā ar tādām sistēmām kā GDPR.
Galvenie secinājumi
- localStorage pastāv neierobežoti, līdz tas tiek skaidri iztīrīts; sessionStorage tiek dzēsts, kad cilne vai logs tiek aizvērts.
- Abas krātuves ir pakļautas krustpunktu skriptu (XSS) uzbrukumiem un nepiedāvā iebūvētu šifrēšanu.
- Ne localStorage, ne sessionStorage dati automātiski netiek nosūtīti uz serveri, atšķirībā no sīkdatnēm, taču abus pilnībā var lasīt jebkurš JavaScript, kas darbojas tajā pašā izcelsmē.
- Trešo pušu skripti, kas ielādēti lapā, var piekļūt localStorage datiem, ja tie darbojas tajā pašā izcelsmes kontekstā.
- Saskaņā ar GDPR, neizšķirīgu datu glabāšana localStorage bez lietotāja piekrišanas ir atbilstības pārkāpums, tāpat kā izsekošanas sīkdatņu ievietošana.
- Jutīgus datus, piemēram, autentifikācijas žetonus, paroles un personiski identificējamu informāciju (PII), nekad nedrīkst glabāt nevienā mehānismā bez papildu drošības slāņiem.
- Privātā/incognito pārlūkošana ierobežo localStorage pastāvību, bet neizslēdz sessionStorage riskus sesijas laikā.
- Izstrādātājiem vajadzētu dot priekšroku sessionStorage pagaidu stāvoklim, servera puses sesijām vai HttpOnly sīkdatnēm autentifikācijai, kā arī piekrišanas pārvaldības platformai, piemēram, Biscotti CMP, lai pārvaldītu krātuves piekrišanu.
Kāda ir atšķirība starp SessionStorage un LocalStorage?
SessionStorage un localStorage ir abas HTML5 tīmekļa krātuves API daļas, taču tās kalpo atšķirīgiem mērķiem, ko nosaka to pastāvība un cilnes apjoma uzvedība.
localStorage glabā atslēgas-vērtību pārus bez derīguma termiņa. Dati izdzīvo pārlūkprogrammas restartēšanas, sistēmas restartēšanas un neierobežotas neaktivitātes periodus, līdz lietotājs vai lietojumprogramma to skaidri noņem. Tas tiek koplietots visās cilnēs un logos, kas darbojas tajā pašā izcelsmē (protokols + domēns + ports). [1][5]
sessionStorage glabā datus tikai lapas sesijas laikā. Kad lietotājs aizver cilni vai logu, dati izzūd. Kritiski, katra cilne uztur savu izolēto sessionStorage, atverot to pašu URL otrajā cilnē, netiek koplietoti pirmās cilnes sessionStorage dati. [1]
| Iezīme | localStorage | sessionStorage |
|---|---|---|
| Pastāvība | Neierobežota | Tikai cilnes/loga mūža laikā |
| Koplietots starp cilnēm | Jā (tajā pašā izcelsmē) | Nē (per-cilnes izolācija) |
| Izdzīvo lapas atkārtotu ielādi | Jā | Jā |
| Izdzīvo cilnes aizvēršanu | Jā | Nē |
| Krātuves ietilpība | ~5-10 MB uz izcelsmi | ~5-10 MB uz izcelsmi |
| Servera pārsūtīšana | Nē | Nē |
| HttpOnly aizsardzība | Nav pieejama | Nav pieejama |
Abas API ievēro vienas izcelsmes politiku, tāpēc lapa https://example.com nevar lasīt krātuvi, ko iestatījusi https://otherdomain.com. [4]
Vai localStorage ir privātuma riski salīdzinājumā ar sessionStorage?
Jā, localStorage rada ievērojami augstākus privātuma riskus nekā sessionStorage, galvenokārt tā neierobežotās pastāvības un krustcilņu pieejamības dēļ.
Dati, kas rakstīti localStorage, var uzkrāties mēnešu vai gadu laikā bez lietotāja apzināšanās. Reklāmas un analītikas piegādātāji vēsturiski ir izmantojuši localStorage kā "super-sīkdatni", izsekošanas identifikatoru, kas izdzīvo sīkdatņu dzēšanu, jo lielākā daļa lietotāju nedomā par pārlūkprogrammas krātuves manuālu iztīrīšanu. sessionStorage, savukārt, pašiznīcina, kad cilne tiek aizvērta, padarot to par daudz mazāk noderīgu izsekošanas vektoru.
Galvenie privātuma riska faktori, kas raksturīgi localStorage:
- Pastāvīgi izsekošanas identifikatori: Unikāls ID, kas glabāts localStorage, var izsekot lietotāju vairākos apmeklējumos bez jebkādas servera puses sīkdatnes.
- Datu noplūde starp cilnēm: Jebkurš skripts, kas darbojas jebkurā cilnē tajā pašā izcelsmē, var lasīt visus localStorage datus.
- Krātuves notikumu izplatīšana: Izmaiņas localStorage izraisa
storagenotikumu citās atvērtajās cilnēs no tās pašas izcelsmes, ļaujot veikt datu sinhronizāciju starp cilnēm, ko lietotāji nevar novērot. [5] - Nav automātiskas derīguma termiņa: Atšķirībā no sīkdatnēm, kurām ir
Max-AgeunExpiresatribūti, localStorage nav TTL mehānisma.
Vai vietnes var izsekot lietotājus, izmantojot localStorage un sessionStorage?
Vietnes var un izmanto localStorage pastāvīgai izsekošanai. sessionStorage ir mazāk noderīga izsekošanai, taču joprojām rada riskus sesijas laikā.
Viena JavaScript rindiņa, localStorage.setItem('uid', 'abc123'), izveido pastāvīgu identifikatoru, kas izdzīvo sīkdatņu dzēšanu. Šī tehnika, ko dažreiz sauc par "evercookie" vai krātuves balstītu atjaunošanu, ir dokumentēta privātuma pētījumos un ir iemesls, kāpēc regulatori arvien vairāk uzskata localStorage par tādām pašām piekrišanas prasībām kā sīkdatnēm.
sessionStorage var izsekot uzvedību vienas sesijas laikā (lapas plūsma, formas ievades, navigācijas modeļi), bet šie dati izzūd, kad cilne tiek aizvērta, ierobežojot tā lietderību ilgtermiņa profilēšanai.
Cik ilgi dati paliek sessionStorage salīdzinājumā ar localStorage?
localStorage dati paliek līdz tie tiek skaidri izdzēsti, vai nu lietotājam iztīrot pārlūkprogrammas krātuvi, vai vietnei izsaucot localStorage.removeItem() vai localStorage.clear(), vai pārlūkprogramma piemērojot krātuves kvotas. [2]
sessionStorage dati tiek automātiski dzēsti, kad cilne vai logs, kas tos izveidoja, tiek aizvērts. Tie izdzīvo lapas atkārtotu ielādi tajā pašā cilnē, bet netiek pārsūtīti uz jaunām cilnēm, pat ja lietotājs dažās pārlūkprogrammās dublē cilni. [1]
Praktiska nozīme: Ja izstrādātājs glabā sesijas žetonu localStorage, nevis sessionStorage, šis žetons paliek ierīcē pēc tam, kad lietotājs izrakstās, ja vien lietojumprogramma to skaidri neizņem. Tas ir izplatīta un sekas nesoša kļūda.
Vai SessionStorage ir privātāka nekā localStorage?
Lielākajā daļā privātuma lietojumu jā, sessionStorage ir privātumam draudzīgāka izvēle. Tās automātiskā dzēšana, kad cilne tiek aizvērta, nozīmē, ka dati nepaliek, samazinot risku no ierīču koplietošanas, nozagtiem ierīcēm vai forensiskās analīzes.
Tomēr sessionStorage nav dabiski "privāta". Aktīvās sesijas laikā tā ir tikpat neaizsargāta pret XSS uzbrukumiem kā localStorage. Jebkurš injicēts skripts var izsaukt sessionStorage.getItem() un reālā laikā iznīcināt datus. [3]
Izvēlieties sessionStorage, ja: dati ir nepieciešami tikai pašreizējai lietotāja mijiedarbībai (piemēram, vairāku soļu formas stāvoklim, vienreizējiem navigācijas žetoniem).
Izvēlieties localStorage, ja: dati patiešām ir jāpastāv starp sesijām (piemēram, lietotāja UI preferences, ne-jutīgas iestatījumi), un pārliecinieties, ka tajā nav nekā personīgi identificējama.
Kādi personīgie dati nekad nedrīkst ietilpt localStorage?
Šādas datu kategorijas nekad nedrīkst glabāt localStorage (un tām jābūt apstrādātām ar ārkārtīgu piesardzību pat sessionStorage): [3]
- Autentifikācijas žetoni (JWT, OAuth žetoni, sesijas ID)
- Paroles vai paroļu hashes
- Kredītkartes vai maksājumu informācija
- Valdības izsniegtie ID numuri vai Sociālās apdrošināšanas numuri
- Pilni vārdi, kas apvienoti ar e-pasta adresēm vai tālruņu numuriem
- Medicīniskie vai veselības ieraksti
- Jebkuri dati, kas klasificēti kā "īpaša kategorija" saskaņā ar GDPR (biometriskie dati, veselības dati, politiskās domas)
Dati, kas glabāti gan localStorage, gan sessionStorage, pēc noklusējuma nav šifrēti. Ikviens, kam ir fiziska piekļuve ierīcei, vai jebkurš skripts, kas spēj izpildīties lapā, var tos lasīt parastā tekstā. [3]
Vai trešo pušu skripti var piekļūt localStorage datiem?
Trešo pušu skripti var piekļūt localStorage datiem, ja tie tiek ielādēti un izpildīti tajā pašā izcelsmē kā hosta lapa. Tas ir kritisks un bieži nenovērtēts risks.
Kad vietne iekļauj trešo pušu analītikas vai reklāmas skriptu, izmantojot <script> tagu, šis skripts darbojas hosta lapas izcelsmes kontekstā. Tas var brīvi lasīt un rakstīt uz vietnes localStorage. Vienas izcelsmes politika nepasargā pret skriptiem, kas ir apzināti vai neapzināti iekļauti lapā. [4]
Ko tas nozīmē praksē: Ja vietne glabā lietotāja identifikatoru localStorage un arī ielādē trešo pušu reklāmas skriptu, šis reklāmas skripts var izlasīt identifikatoru un sasaistīt to ar krustpunktu uzvedības datiem, bez lietotāja zināšanām vai piekrišanas.
Tas ir viens no iemesliem, kāpēc piekrišanas pārvaldības platformas ir svarīgas. Biscotti CMP ļauj vietnēm pārvaldīt un dokumentēt lietotāju piekrišanu krātuves operācijām, tostarp localStorage balstītai izsekošanai, palīdzot vietnēm izpildīt savas saistības saskaņā ar GDPR un līdzīgām sistēmām.
Kādas ir GDPR sekas, izmantojot localStorage?
Saskaņā ar GDPR jebkura personisko datu vai izsekošanas identifikatoru glabāšana, neatkarīgi no tehniskā mehānisma, prasa likumīgu pamatu. Neizšķirīgai izsekošanai, izmantojot localStorage, šis pamats gandrīz vienmēr ir skaidra lietotāja piekrišana. [2]
Eiropas Datu aizsardzības padome ir apstiprinājusi, ka localStorage, ko izmanto analītikai, reklāmai vai lietotāju profilēšanai, ietilpst tajās pašās piekrišanas prasībās kā sīkdatnes. Vietnes, kas ievieto izsekošanas identifikatorus localStorage bez iepriekšējas piekrišanas, saskaras ar tādām pašām izpildes sekām kā tās, kas izmanto neapstiprinātas sīkdatnes.
Atbilstības kontrolsaraksts localStorage saskaņā ar GDPR:
- Audita visus localStorage atslēgas, ko raksta pirmās puses un trešo pušu skripti.
- Klasificējiet katru atslēgu: vai tā ir stingri nepieciešama pakalpojumam, vai tā tiek izmantota analītikai/reklāmai?
- Neizšķirīgai glabāšanai ierobežojiet rakstīšanas operāciju aiz dokumentētas lietotāja piekrišanas.
- Nodrošiniet lietotājiem skaidru mehānismu, lai atsauktu piekrišanu un izsauktu krātuves dzēšanu.
- Dokumentējiet datu kontroliera likumīgo interesi vai piekrišanas ierakstu.
Pareizi konfigurēta piekrišanas pārvaldības platforma, piemēram, Biscotti CMP, var automatizēt lielāko daļu šī piekrišanas dzīves cikla.
Vai localStorage var piekļūt no dažādām vietnēm?
Nē. localStorage ir stingri ierobežota uz izcelsmi (protokols + domēns + porta kombinācija), kas to izveidoja. Skripts uz https://siteA.com nevar lasīt localStorage datus, ko iestatījusi https://siteB.com. [4]
Tomēr šai aizsardzībai ir ierobežojumi. Ja viens reklāmas vai analītikas piegādātājs ielādē savus skriptus gan siteA.com, gan siteB.com, katra instance neatkarīgi raksta uz attiecīgās vietnes localStorage. Piegādātājs pēc tam sasaista datus servera pusē, efektīvi sasniedzot krustpunktu izsekošanu, neizjaucot vienas izcelsmes politiku.
Kā privātā režīma un incognito pārlūkošana ietekmē localStorage?
Privātā/incognito pārlūkošana izveido pagaidu krātuves nodalījumu, kas tiek dzēsts, kad privātā logs tiek aizvērts. localStorage, kas rakstīts incognito sesijas laikā, nepaliek galvenajā pārlūkprogrammas profilā un nav pieejams parastajām pārlūkošanas logiem.
sessionStorage uzvedas tāpat incognito kā parastajā pārlūkošanā: tas tiek dzēsts, kad cilne tiek aizvērta.
Svarīgas piezīmes:
- Aktīvās incognito sesijas laikā localStorage joprojām ir lasāms no visiem skriptiem, kas darbojas šīs sesijas vienas izcelsmes kontekstā.
- Incognito režīms neizslēdz reāllaika XSS balstītu datu iznīcināšanu.
- Dažas pārlūkprogrammas sinhronizē localStorage starp ierīcēm, ja lietotājs ir pierakstījies pārlūkprogrammas sinhronizācijā, kas var pārvietot "vietējos" datus uz mākoņa infrastruktūru.
Kā es varu iztīrīt SessionStorage un localStorage privātuma nolūkos?
Pārlūkprogrammas krātuves tīrīšana ir vienkārša, taču prasa apzinātu rīcību, jo pārlūkprogrammas to automātiski nedara localStorage.
Pārlūkprogrammas līmeņa tīrīšana:
- Chrome: Iestatījumi > Privātums un drošība > Notīrīt pārlūkošanas datus > Kešotās attēlus un failus + Vietnes dati
- Firefox: Iestatījumi > Privātums un drošība > Sīkdatnes un vietnes dati > Notīrīt datus
- Safari: Iestatījumi > Privātums > Pārvaldīt vietnes datus
Programmatiska tīrīšana (izstrādātājiem):
localStorage.clear()noņem visas atslēgas izcelsmei.sessionStorage.clear()noņem visas atslēgas pašreizējās cilnes sesijai.localStorage.removeItem('keyName')noņem konkrētu atslēgu.
Lietotājiem, kas uztraucas par izsekošanu: tīrīšana "vietnes datu" vai "sīkdatņu un krātuves" pārlūkprogrammas iestatījumos noņem gan localStorage, gan sessionStorage saturu visām vietnēm. Pārlūkprogrammas paplašinājumi, kas paredzēti privātumam, var automatizēt šo procesu pēc vietnes vai sesijas.
Kādas ir izplatītākās privātuma kļūdas, ko izstrādātāji pieļauj ar tīmekļa krātuvi?
Visnopietnākās kļūdas dalās ar kopīgu sakni: klienta puses krātuves uzskatīšana par drošu servera puses datu bāzi.
- JWT glabāšana localStorage: Autentifikācijas žetoni, kas glabāti localStorage, ir pieejami jebkuram skriptam lapā. Viena XSS ievainojamība atklāj katra lietotāja žetonu. Izmantojiet HttpOnly sīkdatnes autentifikācijas žetoniem.
- Nav derīguma termiņa loģikas: localStorage nav TTL. Izstrādātāji, kas glabā datus, neizveidojot derīguma termiņa loģiku, atstāj novecojušus, jutīgus datus ierīcēs neierobežoti.
- Pieņemot, ka vienas izcelsmes politika nozīmē drošību: Vienas izcelsmes politika bloķē ārējās vietnes, nevis ļaunprātīgus skriptus, kas ielādēti no tās pašas vietnes (XSS, kompromitētas trešo pušu bibliotēkas).
- Noraidot trešo pušu skriptu piekļuvi: Iekļaujot analītikas vai reklāmas skriptus, neauditorējot, ko tie lasa no localStorage.
- Nav piekrišanas barjeras izsekošanas krātuvei: Rakstot analītikas identifikatorus localStorage pirms lietotāja piekrišanas iegūšanas, tieši pārkāpjot GDPR. [2]
- Jutīgas PII glabāšana: Kešojot API atbildes, kas ietver pilnus lietotāju profilus localStorage "veiktspējas" nolūkos, neņemot vērā izplatīšanas virsmu.
Vai IndexedDB ir privātāka nekā localStorage?
IndexedDB nav dabiski privātāka nekā localStorage. Abas tiek regulētas ar vienas izcelsmes politiku, abas ir pieejamas JavaScript, kas darbojas lapā, un abas ir neaizsargātas pret XSS uzbrukumiem.
IndexedDB piedāvā lielāku krātuves ietilpību un atbalsta strukturētus datus un bināros blobus, padarot to piemērotu sarežģītām offline lietojumprogrammām. Bet no privātuma un drošības viedokļa riski ir salīdzināmi. Dati, kas glabāti IndexedDB, arī pēc noklusējuma nav šifrēti, un tie pastāv neierobežoti, ja vien tie netiek skaidri izdzēsti.
Izvēle starp IndexedDB un localStorage jābalsta uz datu sarežģītību un apjoma prasībām, nevis privātuma pieņēmumiem. Neviens no tiem nav piemērots jutīgiem personīgiem datiem bez lietojumprogrammas slāņa šifrēšanas un stingrām piekļuves kontroles.
Secinājums
Diskusija par SessionStorage pret LocalStorage: Privātuma sekas tīmekļa krātuves API nav tikai tehnisks piezīme, tai ir tiešas sekas lietotāju privātumam, regulatīvai atbilstībai un lietojumprogrammu drošībai. localStorage neierobežotā pastāvība un krustcilņu pieejamība padara to par augsta riska krātuves mehānismu, ja to nepareizi izmanto, savukārt sessionStorage automātiskā dzēšana, kad cilne tiek aizvērta, padara to par aizsargājamu izvēli pagaidu stāvoklim.
Rīcības soļi izstrādātājiem un vietņu īpašniekiem 2026. gadā:
- Audita visus localStorage un sessionStorage izmantojumus visos pirmās puses un trešo pušu skriptos, izmantojot pārlūkprogrammas izstrādātāja rīkus (Lietojumprogrammas cilne).
- Nekavējoties noņemiet jebkādus autentifikācijas žetonus, PII vai jutīgus identifikatorus no klienta puses krātuves.
- Aizvietojiet localStorage balstīto autentifikācijas žetonu glabāšanu ar HttpOnly, Secure sīkdatnēm, ko pārvalda servera pusē.
- Ieviesiet piekrišanas pārvaldības darba plūsmu, izmantojot platformu, piemēram, Biscotti CMP, lai ierobežotu neizšķirīgu localStorage rakstīšanu aiz dokumentētas lietotāja piekrišanas.
- Izveidojiet derīguma termiņa loģiku jebkuriem localStorage datiem, kas jāpastāv, un nodrošiniet tīrīšanu, kad izrakstāties.
- Veiciet trešo pušu skriptu auditu, lai saprastu, kāds ārējais kods var lasīt no jūsu izcelsmes krātuves.
- Apmāciet izstrādātāju komandas par XSS novēršanu kā galveno uzbrukuma vektoru pret abām krātuves veidiem.
Tīmekļa krātuves API ir jaudīgi rīki. Ja tos izmanto bez privātuma disciplīnas, tie kļūst par atbildības vektoriem. Ja tos izmanto ar apzinātu ierobežošanu, piekrišanas pārvaldību un drošības higiēnu, tie kalpo savam paredzētajam mērķim, neapdraudot lietotājus, kuri uzticas jūsu lietojumprogrammai.
Biežāk uzdotie jautājumi
Q: Kāda ir galvenā atšķirība starp sessionStorage un localStorage? localStorage saglabā datus neierobežoti starp sesijām un tiek koplietots visās tajā pašā izcelsmē esošajās cilnēs. sessionStorage glabā datus tikai pašreizējās cilnes mūža laikā un tiek automātiski dzēsts, kad cilne tiek aizvērta.
Q: Vai localStorage var izmantot, lai izsekotu lietotājus bez sīkdatnēm? Jā. Unikāls identifikators, kas glabāts localStorage, izdzīvo sīkdatņu dzēšanu un var tikt izmantots, lai izsekotu lietotājus vairākos apmeklējumos uz tās pašas vietnes, funkcionējot kā pastāvīgs izsekošanas mehānisms.
Q: Vai sessionStorage ir droša paroles glabāšanai? Nē. sessionStorage nav šifrēta un ir pieejama jebkuram JavaScript, kas darbojas lapā, tostarp injicētiem ļaunprātīgiem skriptiem. Paroles nekad nedrīkst glabāt nevienā klienta puses krātuves mehānismā.
Q: Vai GDPR attiecas uz localStorage? Jā. Saskaņā ar GDPR, izsekošanas identifikatoru vai personisko datu glabāšana localStorage bez likumīga pamata, parasti skaidras lietotāja piekrišanas neizšķirīgiem mērķiem, ir atbilstības pārkāpums, kas ir līdzvērtīgs neapstiprinātas sīkdatņu izmantošanai.
Q: Vai trešo pušu skripti var lasīt manus localStorage datus?
Jā, ja šie skripti tiek ielādēti un izpildīti tajā pašā izcelsmē. Trešo pušu analītikas vai reklāmas skripti, kas iekļauti, izmantojot <script> tagus, darbojas hosta lapas izcelsmes kontekstā un var lasīt visus localStorage datus šai izcelsmei.
Q: Vai sīkdatņu dzēšana arī iztīra localStorage? Ne vienmēr. Lielākajā daļā pārlūkprogrammu "sīkdatņu" tīrīšana pati par sevi neiztīra localStorage. Lietotājiem jāiztīra konkrēti "vietnes dati" vai "sīkdatnes un citi vietnes dati", lai noņemtu localStorage saturu.
Q: Vai incognito režīms ir drošs pret localStorage izsekošanu? Incognito režīms novērš localStorage datu saglabāšanu pēc privātā loga aizvēršanas, taču aktīvās incognito sesijas laikā localStorage joprojām ir lasāms no visiem skriptiem lapā.
Q: Ko man izmantot vietā localStorage autentifikācijas žetoniem? Izmantojiet HttpOnly, Secure, SameSite sīkdatnes, ko pārvalda servera pusē. Šīs sīkdatnes nav pieejamas JavaScript, novēršot XSS balstītu žetonu zādzības risku, ko nes localStorage.
Q: Vai IndexedDB ir drošāka nekā localStorage? Nē. IndexedDB ir pakļauta tādām pašām XSS ievainojamībām un vienas izcelsmes politikai kā localStorage. Tā piedāvā lielāku ietilpību un datu struktūras atbalstu, bet nekādas papildu privātuma vai drošības garantijas.
Q: Cik daudz datu var saturēt localStorage un sessionStorage? Lielākā daļa mūsdienu pārlūkprogrammu piešķir aptuveni 5 līdz 10 MB krātuves uz izcelsmi katram krātuves veidam, kas ir ievērojami vairāk nekā 4 KB ierobežojums, kas ir raksturīgs sīkdatnēm. [2]
Atsauces
[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