Rövid válasz: A sessionStorage és a localStorage egyaránt böngészőalapú webes tárolási API-k, amelyek lehetővé teszik a weboldalak számára, hogy adatokat tároljanak a felhasználó eszközén, de alapvetően különböznek az adatmegőrzés és a hatókör tekintetében. A localStorage határozatlan ideig megőrzi az adatokat a munkamenetek és lapok között, míg a sessionStorage törli az adatokat, amikor a böngésző lap bezárul. Adatvédelmi szempontból a localStorage lényegesen nagyobb kockázatot jelent, mivel az adatok lejárati idő nélkül megmaradnak, így vonzóbb célponttá válnak a nyomon követés, az ujjlenyomat-készítés és a szabályozási ellenőrzés számára az olyan keretrendszerek, mint a GDPR alapján.
Főbb tudnivalók
- A localStorage határozatlan ideig megmarad, amíg kifejezetten nem törlik; a sessionStorage törlődik, amikor a lap vagy ablak bezárul.
- Mindkét tárolási típus sebezhető a cross-site scripting (XSS) támadásokkal szemben, és nem kínál beépített titkosítást.
- Sem a localStorage, sem a sessionStorage adatai nem kerülnek automatikusan továbbításra a szerverre, ellentétben a sütikkel, de mindkettő teljes mértékben olvasható bármely JavaScript által, amely ugyanazon az eredeten fut.
- Az oldalon betöltött harmadik féltől származó szkriptek hozzáférhetnek a localStorage adataihoz, ha ugyanazon az eredeti környezetben futnak.
- A GDPR értelmében a nem alapvető adatok localStorage-ban történő tárolása felhasználói hozzájárulás nélkül szabálysértésnek minősül, ugyanúgy, mint a nyomkövető sütik elhelyezése.
- Érzékeny adatokat, például hitelesítési tokeneket, jelszavakat és személyazonosításra alkalmas adatokat (PII) soha nem szabad tárolni egyik mechanizmusban sem további biztonsági rétegek nélkül.
- A privát/inkognitó böngészés korlátozza a localStorage adatmegőrzését, de nem szünteti meg a sessionStorage kockázatait egy munkameneten belül.
- A fejlesztőknek előnyben kell részesíteniük a sessionStorage-t az ideiglenes állapotokhoz, a szerveroldali munkameneteket vagy a HttpOnly sütiket a hitelesítéshez, és egy hozzájárulás-kezelő platformot, például a Biscotti CMP -t a tárolási hozzájárulás kezeléséhez.
Mi a különbség a SessionStorage és a LocalStorage között?
A sessionStorage és a localStorage egyaránt az HTML5 Web Storage API része, de eltérő célokat szolgálnak, amelyeket az adatmegőrzésük és a lap-hatókör viselkedésük határoz meg.
A localStorage kulcs-érték párokat tárol lejárati dátum nélkül. Az adatok túlélik a böngésző újraindítását, a rendszer újraindítását és a határozatlan ideig tartó inaktivitást, amíg a felhasználó vagy az alkalmazás kifejezetten el nem távolítja azokat. Megosztott minden lap és ablak között, amelyek ugyanazon az eredeten (protokoll + domain + port) működnek. [1][5]
A sessionStorage csak az oldal munkamenetének élettartamára tárol adatokat. Amikor a felhasználó bezárja a lapot vagy ablakot, az adatok eltűnnek. Kritikus fontosságú, hogy minden lap fenntartja a saját izolált sessionStorage-ét, ugyanazon URL megnyitása egy második lapon nem osztja meg az első lap sessionStorage adatait. [1]
| Funkció | localStorage | sessionStorage |
|---|---|---|
| Adatmegőrzés | Határozatlan | Csak a lap/ablak élettartama |
| Megosztott lapok között | Igen (azonos eredet) | Nem (lap-specifikus izoláció) |
| Túléli az oldal újratöltését | Igen | Igen |
| Túléli a lap bezárását | Igen | Nem |
| Tárolási kapacitás | ~5-10 MB eredetenként | ~5-10 MB eredetenként |
| Szerverre továbbítás | Nem | Nem |
| HttpOnly védelem | Nem elérhető | Nem elérhető |
Mindkét API betartja az azonos eredetű házirendet, így a https://example.com oldalon lévő oldal nem olvashatja a https://otherdomain.com által beállított tárolót. [4]
Jelent-e adatvédelmi kockázatot a localStorage a sessionStorage-hez képest?
Igen, a localStorage lényegesen nagyobb adatvédelmi kockázatokat hordoz, mint a sessionStorage, elsősorban a határozatlan ideig tartó megőrzése és a lapok közötti hozzáférhetősége miatt.
A localStorage-ba írt adatok hónapokig vagy évekig felhalmozódhatnak a felhasználó tudta nélkül. A hirdetők és az analitikai szolgáltatók történelmileg használták a localStorage-t "szuper-sütiként", egy olyan nyomkövető azonosítóként, amely túléli a sütik törlését, mert a legtöbb felhasználó nem gondol arra, hogy manuálisan törölje a böngésző tárolóját. A sessionStorage ezzel szemben a lap bezárásakor önmegsemmisül, így sokkal kevésbé hasznos nyomkövetési vektor.
A localStorage-ra jellemző fő adatvédelmi kockázati tényezők:
- Tartós nyomkövető azonosítók: A localStorage-ban tárolt egyedi azonosító nyomon követheti a felhasználót több látogatás során is szerveroldali süti nélkül.
- Lapok közötti adatszivárgás: Bármely szkript, amely ugyanazon eredet bármely lapján fut, olvashatja az összes localStorage adatot.
- Tárolási események sugárzása: A localStorage változásai
storageeseményt váltanak ki más nyitott lapokon ugyanazon eredetből, lehetővé téve a lapok közötti adatszinkronizálást, amelyet a felhasználók nem figyelhetnek meg. [5] - Nincs automatikus lejárat: A sütikkel ellentétben, amelyek támogatják a
Max-AgeésExpiresattribútumokat, a localStorage-nak nincs TTL mechanizmusa.
Nyomon követhetik-e a weboldalak a felhasználókat a localStorage és a sessionStorage segítségével?
A weboldalak használhatják és használják is a localStorage-t tartós nyomon követésre. A sessionStorage kevésbé hasznos a nyomon követéshez, de még mindig jelent kockázatot a munkameneten belüli megfigyelésre.
Egyetlen JavaScript sor, a localStorage.setItem('uid', 'abc123'), egy tartós azonosítót hoz létre, amely túléli a sütik törlését. Ezt a technikát, amelyet néha "evercookie"-nak vagy tárolás alapú újraélesztésnek neveznek, adatvédelmi kutatások dokumentálták, és ez az oka annak, hogy a szabályozók egyre inkább ugyanazokat a hozzájárulási szabályokat alkalmazzák a localStorage-ra, mint a sütikre.
A sessionStorage képes nyomon követni a viselkedést egyetlen munkameneten belül (oldalfolyam, űrlapbevitelek, navigációs minták), de ezek az adatok eltűnnek, amikor a lap bezárul, korlátozva a hosszú távú profilalkotás hasznosságát.
Mennyi ideig maradnak az adatok a SessionStorage-ben és a LocalStorage-ban?
A localStorage adatok addig maradnak, amíg kifejezetten nem törlik őket, akár a felhasználó által a böngésző tárolójának törlésével, akár a weboldal által a localStorage.removeItem() vagy localStorage.clear() hívásával, vagy a böngésző által a tárolási kvóták érvényesítésével. [2]
A sessionStorage adatok automatikusan törlődnek, amikor az azt létrehozó lap vagy ablak bezárul. Túléli az oldal újratöltését ugyanazon a lapon belül, de nem kerül át új lapokra, még akkor sem, ha a felhasználó egyes böngészőkben megkettőzi a lapot. [1]
Gyakorlati következmény: Ha egy fejlesztő munkamenet-tokent tárol a localStorage-ban a sessionStorage helyett, az a token az eszközön marad a felhasználó kijelentkezése után is, hacsak az alkalmazás kifejezetten el nem távolítja. Ez egy gyakori és jelentős hiba.
Adatvédelmi szempontból privátabb a SessionStorage, mint a localStorage?
A legtöbb adatvédelmi felhasználási esetre igen, a sessionStorage az adatvédelmi szempontból tiszteletreméltóbb választás. Az automatikus törlése a lap bezárásakor azt jelenti, hogy az adatok nem maradnak meg, csökkentve az eszközmegosztásból, ellopott eszközökből vagy törvényszéki elemzésből eredő kitettséget.
A sessionStorage azonban nem eredendően "privát". Egy aktív munkameneten belül ugyanúgy sebezhető az XSS támadásokkal szemben, mint a localStorage. Bármely beillesztett szkript meghívhatja a sessionStorage.getItem() függvényt, és valós időben exfiltrálhatja az adatokat. [3]
Válassza a sessionStorage-t, ha: az adatokra csak az aktuális felhasználói interakcióhoz van szükség (pl. többlépéses űrlap állapota, egyszeri navigációs tokenek).
Válassza a localStorage-t, ha: az adatoknak valóban meg kell maradniuk a munkamenetek között (pl. felhasználói felület beállításai, nem érzékeny beállítások), és győződjön meg róla, hogy nem tartalmaz személyazonosításra alkalmas adatokat.
Milyen személyes adatokat soha ne tároljunk a localStorage-ban?
A következő adatkategóriákat soha nem szabad tárolni a localStorage-ban (és még a sessionStorage-ban is rendkívül óvatosan kell kezelni): [3]
- Hitelesítési tokenek (JWT-k, OAuth tokenek, munkamenet-azonosítók)
- Jelszavak vagy jelszó-hash-ek
- Hitelkártya- vagy fizetési információk
- Kormány által kiadott azonosító számok vagy társadalombiztosítási számok
- Teljes nevek e-mail címekkel vagy telefonszámokkal kombinálva
- Orvosi vagy egészségügyi nyilvántartások
- Bármely adat, amelyet a GDPR "különleges kategóriájú" adatként osztályoz (biometrikus adatok, egészségügyi adatok, politikai vélemények)
A localStorage-ban és a sessionStorage-ban tárolt adatok alapértelmezés szerint titkosítatlanok. Bárki, aki fizikai hozzáféréssel rendelkezik az eszközhöz, vagy bármely szkript, amely képes futni az oldalon, olvashatja azokat egyszerű szövegként. [3]
Hozzáférhetnek-e harmadik féltől származó szkriptek a localStorage adataihoz?
A harmadik féltől származó szkriptek hozzáférhetnek a localStorage adataihoz, ha ugyanazon az eredeten belül töltődnek be és futnak, mint a gazdaoldal. Ez egy kritikus és gyakran alábecsült kockázat.
Amikor egy weboldal egy harmadik féltől származó analitikai vagy hirdetési szkriptet ágyaz be egy <script> címke segítségével, az a szkript a gazdaoldal eredeti környezetében fut. Szabadon olvashatja és írhatja a webhely localStorage-ját. Az azonos eredetű házirend nem véd az olyan szkriptek ellen, amelyeket szándékosan vagy véletlenül beillesztettek az oldalra. [4]
Mit jelent ez a gyakorlatban: Ha egy webhely felhasználói azonosítót tárol a localStorage-ban, és egy harmadik féltől származó hirdetési szkriptet is betölt, az a hirdetési szkript elolvashatja az azonosítót, és összekapcsolhatja azt a webhelyek közötti viselkedési adatokkal, a felhasználó tudta vagy hozzájárulása nélkül.
Ez az egyik oka annak, hogy a hozzájárulás-kezelő platformok miért fontosak. A Biscotti CMP lehetővé teszi a webhelyek számára, hogy kezeljék és dokumentálják a felhasználói hozzájárulást a tárolási műveletekhez, beleértve a localStorage alapú nyomon követést is, segítve a webhelyeket a GDPR és hasonló keretrendszerek szerinti kötelezettségeik teljesítésében.
Milyen GDPR vonatkozásai vannak a localStorage használatának?
A GDPR értelmében a személyes adatok vagy nyomkövető azonosítók bármilyen tárolása, függetlenül a technikai mechanizmustól, jogalapot igényel. A localStorage-on keresztül történő nem alapvető nyomon követés esetében ez az alap szinte mindig kifejezett felhasználói hozzájárulás. [2]
Az Európai Adatvédelmi Testület megerősítette, hogy az analitikához, hirdetéshez vagy felhasználói profilalkotáshoz használt localStorage-ra ugyanazok a hozzájárulási követelmények vonatkoznak, mint a sütikre. Azok a webhelyek, amelyek előzetes hozzájárulás nélkül helyeznek el nyomkövető azonosítókat a localStorage-ban, ugyanazokkal a végrehajtási kockázatokkal szembesülnek, mint azok, amelyek hozzájárulás nélküli sütiket használnak.
GDPR megfelelőségi ellenőrzőlista a localStorage-hoz:
- Ellenőrizze az összes localStorage kulcsot, amelyet első és harmadik féltől származó szkriptek írnak.
- Osztályozza az egyes kulcsokat: szigorúan szükséges-e a szolgáltatáshoz, vagy analitikához/hirdetéshez használják?
- A nem alapvető tárolás esetén a írási műveletet dokumentált felhasználói hozzájárulás mögé kell helyezni.
- Biztosítson a felhasználók számára egyértelmű mechanizmust a hozzájárulás visszavonására és a tárolás törlésének kiváltására.
- Dokumentálja az adatkezelő jogos érdekét vagy hozzájárulási nyilvántartását.
Egy megfelelően konfigurált hozzájárulás-kezelő platform, mint például a Biscotti CMP, automatizálhatja ennek a hozzájárulási életciklusnak nagy részét.
Hozzáférhető-e a localStorage különböző weboldalakról?
Nem. A localStorage szigorúan az azt létrehozó eredetre (protokoll + domain + port kombináció) van korlátozva. Egy szkript a https://siteA.com oldalon nem olvashatja a https://siteB.com által beállított localStorage adatokat. [4]
Ez a védelem azonban korlátozott. Ha egyetlen hirdetési vagy analitikai szolgáltató betölti a szkriptjeit mind a siteA.com, mind a siteB.com oldalon, akkor mindegyik példány függetlenül ír az adott webhely localStorage-jába. A szolgáltató ezután szerveroldalon korrelálja az adatokat, hatékonyan elérve a webhelyek közötti nyomon követést az azonos eredetű házirend megsértése nélkül.
Hogyan befolyásolja az inkognitó mód és a privát böngészés a localStorage-t?
A privát/inkognitó böngészés ideiglenes tárolási partíciót hoz létre, amely törlődik, amikor a privát ablak bezárul. Az inkognitó munkamenet során írt localStorage nem marad meg a fő böngészőprofilban, és nem hozzáférhető a normál böngészőablakokból.
A sessionStorage ugyanúgy viselkedik inkognitó módban, mint a normál böngészés során: törlődik, amikor a lap bezárul.
Fontos figyelmeztetések:
- Egy aktív inkognitó munkameneten belül a localStorage továbbra is olvasható az összes szkript által, amely az adott munkamenet azonos eredetű környezetében fut.
- Az inkognitó mód nem akadályozza meg a valós idejű XSS alapú adatexfiltrációt.
- Egyes böngészők szinkronizálják a localStorage-t az eszközök között, ha a felhasználó be van jelentkezve a böngésző szinkronizálásába, ami a "helyi" adatokat felhőinfrastruktúrába mozgathatja.
Hogyan törölhetem a SessionStorage-t és a LocalStorage-t az adatvédelem érdekében?
A böngésző tárolójának törlése egyszerű, de szándékos cselekvést igényel, mivel a böngészők nem teszik meg automatikusan a localStorage esetében.
Böngésző szintű törlés:
- Chrome: Beállítások > Adatvédelem és biztonság > Böngészési adatok törlése > Gyorsítótárazott képek és fájlok + Webhelyadatok
- Firefox: Beállítások > Adatvédelem és biztonság > Sütik és webhelyadatok > Adatok törlése
- Safari: Beállítások > Adatvédelem > Webhelyadatok kezelése
Programozott törlés (fejlesztők számára):
localStorage.clear()eltávolítja az összes kulcsot az eredetről.sessionStorage.clear()eltávolítja az összes kulcsot az aktuális lap munkamenetéből.localStorage.removeItem('keyName')eltávolít egy adott kulcsot.
A nyomon követés miatt aggódó végfelhasználók számára: a "webhelyadatok" vagy "sütik és tárolás" törlése a böngésző beállításaiban eltávolítja mind a localStorage, mind a sessionStorage tartalmát az összes webhelyről. Az adatvédelemre tervezett böngészőbővítmények automatizálhatják ezt webhelyenként vagy munkamenetenként.
Milyen gyakori adatvédelmi hibákat követnek el a fejlesztők a webes tárolással kapcsolatban?
A legjelentősebb hibák közös gyökérrel rendelkeznek: az ügyféloldali tárolást úgy kezelik, mintha az egy biztonságos szerveroldali adatbázis lenne.
- JWT-k tárolása a localStorage-ban: A localStorage-ban tárolt hitelesítési tokenek hozzáférhetők az oldal bármely szkriptje számára. Egyetlen XSS sebezhetőség minden felhasználó tokenjét felfedi. Használjon HttpOnly sütiket a hitelesítési tokenekhez.
- Nincs lejárati logika: A localStorage-nak nincs TTL-je. Azok a fejlesztők, akik lejárati logika nélkül tárolnak adatokat, elavult, érzékeny adatokat hagynak az eszközökön határozatlan ideig.
- Az azonos eredetű biztonság feltételezése: Az azonos eredetű házirend blokkolja a külső webhelyeket, nem pedig az ugyanazon a webhelyen belülről betöltött rosszindulatú szkripteket (XSS, kompromittált harmadik féltől származó könyvtárak).
- A harmadik féltől származó szkriptek hozzáférésének figyelmen kívül hagyása: Analitikai vagy hirdetési szkriptek beágyazása anélkül, hogy ellenőriznék, mit olvasnak a localStorage-ból.
- Nincs hozzájárulási kapu a nyomkövetési tároláshoz: Analitikai azonosítók írása a localStorage-ba a felhasználói hozzájárulás megszerzése előtt, ami közvetlen GDPR megsértés. [2]
- Felesleges PII tárolása: API válaszok gyorsítótárazása, amelyek teljes felhasználói profilokat tartalmaznak a localStorage-ban "teljesítmény céljából" anélkül, hogy figyelembe vennék a kitettségi felületet.
Privátabb az IndexedDB, mint a localStorage?
Az IndexedDB nem eredendően privátabb, mint a localStorage. Mindkettőre ugyanaz az azonos eredetű házirend vonatkozik, mindkettő hozzáférhető az oldalon futó JavaScript számára, és mindkettő sebezhető az XSS támadásokkal szemben.
Az IndexedDB nagyobb tárolási kapacitást kínál, és támogatja a strukturált adatokat és a bináris blobokat, így alkalmas komplex offline alkalmazásokhoz. De adatvédelmi és biztonsági szempontból a kockázatok összehasonlíthatók. Az IndexedDB-ben tárolt adatok alapértelmezés szerint szintén titkosítatlanok, és határozatlan ideig megmaradnak, hacsak kifejezetten nem törlik őket.
Az IndexedDB és a localStorage közötti választást az adatok komplexitása és a mennyiségi követelmények kell, hogy vezéreljék, nem pedig az adatvédelmi feltételezések. Egyik sem alkalmas érzékeny személyes adatok tárolására alkalmazásszintű titkosítás és szigorú hozzáférés-ellenőrzés nélkül.
Összefoglalás
A SessionStorage vs. LocalStorage: A webes tárolási API-k adatvédelmi vonatkozásai vita nem csupán egy technikai lábjegyzet, hanem közvetlen következményekkel jár a felhasználói adatvédelemre, a szabályozási megfelelőségre és az alkalmazásbiztonságra nézve. A localStorage határozatlan ideig tartó megőrzése és lapok közötti hozzáférhetősége magas kockázatú tárolási mechanizmussá teszi, ha helytelenül használják, míg a sessionStorage automatikus törlése a lap bezárásakor védhetőbb választássá teszi az ideiglenes állapotokhoz.
Cselekvési lépések fejlesztők és weboldal-tulajdonosok számára 2026-ban:
- Ellenőrizze az összes localStorage és sessionStorage használatot az első és harmadik féltől származó szkriptek között a böngésző DevTools (Alkalmazás lap) segítségével.
- Azonnal távolítson el minden hitelesítési tokent, PII-t vagy érzékeny azonosítót az ügyféloldali tárolóból.
- Cserélje le a localStorage alapú hitelesítési token tárolást HttpOnly, Secure, szerveroldalon kezelt sütikre.
- Valósítson meg egy hozzájárulás-kezelési munkafolyamatot, például a Biscotti CMP platformot használva, hogy a nem alapvető localStorage írásokat dokumentált felhasználói hozzájárulás mögé helyezze.
- Építsen lejárati logikát minden olyan localStorage adatba, amelynek meg kell maradnia, és kényszerítse ki a tisztítást kijelentkezéskor.
- Végezzen harmadik féltől származó szkript ellenőrzést, hogy megértse, milyen külső kód olvashatja az eredet tárolóját.
- Képezze a fejlesztőcsapatokat az XSS megelőzésére, mint az elsődleges támadási vektorra mindkét tárolási típus ellen.
A webes tárolási API-k hatékony eszközök. Adatvédelmi fegyelem nélkül felelősségi vektorokká válnak. Szándékos hatókörrel, hozzájárulás-kezeléssel és biztonsági higiéniával használva betöltik rendeltetésüket anélkül, hogy veszélyeztetnék azokat a felhasználókat, akik bíznak az alkalmazásában.
GYIK
K: Mi a fő különbség a sessionStorage és a localStorage között? A localStorage határozatlan ideig megőrzi az adatokat a munkamenetek között, és megosztott az azonos eredetű összes lap között. A sessionStorage csak az aktuális lap élettartamára tárol adatokat, és automatikusan törlődik, amikor a lap bezárul.
K: Használható-e a localStorage a felhasználók nyomon követésére sütik nélkül? Igen. A localStorage-ban tárolt egyedi azonosító túléli a sütik törlését, és felhasználható a felhasználók nyomon követésére ugyanazon a webhelyen több látogatás során, tartós nyomkövetési mechanizmusként működve.
K: Biztonságos-e a sessionStorage jelszavak tárolására? Nem. A sessionStorage nincs titkosítva, és hozzáférhető az oldalon futó bármely JavaScript számára, beleértve a beillesztett rosszindulatú szkripteket is. Jelszavakat soha nem szabad tárolni semmilyen ügyféloldali tárolási mechanizmusban.
K: Vonatkozik-e a GDPR a localStorage-ra? Igen. A GDPR értelmében a nyomkövető azonosítók vagy személyes adatok localStorage-ban történő tárolása jogalap nélkül, jellemzően kifejezett felhasználói hozzájárulás nélkül nem alapvető célokra, szabálysértésnek minősül, ami megegyezik a hozzájárulás nélküli sütihasználattal.
K: Hozzáférhetnek-e harmadik féltől származó szkriptek a localStorage adataimhoz?
Igen, ha ezek a szkriptek ugyanazon az eredeten belül töltődnek be és futnak. A <script> címkékkel beágyazott harmadik féltől származó analitikai vagy hirdetési szkriptek a gazdaoldal eredeti környezetében futnak, és elolvashatják az adott eredet összes localStorage adatát.
K: A sütik törlése törli a localStorage-t is? Nem mindig. A legtöbb böngészőben a "sütik" önmagában történő törlése nem törli a localStorage-t. A felhasználóknak kifejezetten törölniük kell a "webhelyadatokat" vagy a "sütiket és egyéb webhelyadatokat" a localStorage tartalmának eltávolításához.
K: Biztonságos-e az inkognitó mód a localStorage nyomon követésétől? Az inkognitó mód megakadályozza, hogy a localStorage adatok megmaradjanak a privát ablak bezárása után, de egy aktív inkognitó munkameneten belül a localStorage továbbra is olvasható az oldal összes szkriptje által.
K: Mit használjak a localStorage helyett hitelesítési tokenekhez? Használjon HttpOnly, Secure, SameSite sütiket, amelyeket szerveroldalon kezelnek. Ezek a sütik hozzáférhetetlenek a JavaScript számára, kiküszöbölve az XSS alapú tokenlopás kockázatát, amelyet a localStorage hordoz.
K: Biztonságosabb-e az IndexedDB, mint a localStorage? Nem. Az IndexedDB ugyanazoknak az XSS sebezhetőségeknek és az azonos eredetű házirendnek van kitéve, mint a localStorage. Nagyobb kapacitást és adatstruktúra-támogatást kínál, de nem nyújt további adatvédelmi vagy biztonsági garanciákat.
K: Mennyi adatot tárolhat a localStorage és a sessionStorage? A legtöbb modern böngésző körülbelül 5-10 MB tárolóhelyet biztosít eredetenként mindkét tárolási típushoz, ami lényegesen több, mint a sütikre jellemző 4 KB-os korlát. [2]
Hivatkozások
[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