Browserlagring og sikker logout: efterlad ikke brugerdata på enheden

Det korte svar

Behandl logout som mere end en omdirigering til login-siden. Den aktive session skal ugyldiggøres dér, hvor den kan bruges, og browseren skal stoppe aktive forbindelser, fjerne den konkrete brugers lokale data og forhindre følsomme svar i at dukke op igen fra cache. Test derefter med tilbageknap, offline-tilstand, flere faner og en anden bruger i samme browserprofil.

Find alle steder, browseren kan huske noget

Åbn browserens udviklerværktøjer og gennemgå lagring og netværk efter et realistisk brugerforløb. Kodesøgning efter enkelte API-navne er nyttig, men den finder ikke altid data, som et auth-bibliotek, en service worker eller en tredjepartspakke gemmer.

MDN beskriver, at localStoragedeles inden for samme origin og normalt overlever en genstart, menssessionStorage er knyttet til fanens session. IndexedDB og Cache API er andre, separate lagre. Et tomt localStorage beviser derfor ikke, at browseren er ryddet.

Vælg hvad der må overleve – og hvorfor

Lav en lille lagringsoversigt med datakategori, teknisk lager, bruger- eller virksomhedstilknytning, ønsket levetid, oprydningshændelse og konsekvens ved tab eller eksponering. “Det gør biblioteket automatisk” er ikke en dokumenteret politik.

• Offentlige appfiler: Kan ofte caches længe, når filnavne versionsstyres, fordi de ikke indeholder brugerdata.
• Ufarlige præferencer: Tema eller tabelvisning kan typisk overleve logout, hvis de ikke afslører identitet, rolle eller kundedata.
• Brugerdata: Knyt cache og offline-poster til en stabil bruger- og virksomhedsnøgle, og fjern dem ved logout eller kontoskift efter den aftalte regel.
• Usynkroniserede kladder: Beslut om de skal synkroniseres, eksporteres, slettes eller bevares krypteret. Informér brugeren før en destruktiv oprydning.
• Sessionshemmeligheder: OWASP fraråder sessions-id'er i localStorage, fordi JavaScript kan læse lageret. Vælg sessionmekanisme efter arkitektur og risiko; en HttpOnly-cookie kan begrænse JavaScript-adgang, men kræver stadig korrekt cookie- og CSRF-beskyttelse.

Lokal browserlagring bør ikke være den eneste kopi af forretningskritiske data. Browseren kan afvise en skrivning ved opbrugt kvote, og standardlagring kan blive slettet under lagerpres. Appen skal vise, om en kladde kun findes lokalt, afventer synkronisering eller er bekræftet på serveren.

Styr HTTP-cache pr. type svar

HTTP-cache er ikke det samme som appens egen Cache API. Sæt cache-headere på serverens svar ud fra indholdet. MDN præciserer, atno-cachestadig tillader lagring, men kræver validering før almindelig genbrug. Hvis et følsomt svar slet ikke må gemmes, erno-storedet relevante direktiv.

Tilbageknappen kræver sin egen test. Browsere kan gendanne et øjebliksbillede gennem back/forward-cache uden et nyt netværkskald. Appens klienttilstand skal derfor også reagere på en afsluttet session og må ikke vise den gamle brugers data som aktive.

Gør logout til en kontrolleret tilstandsændring

1. 1. Afslut sessionen autoritativt. Brug loginudbyderens eller backendens sign-out og tilbagekaldelse efter den valgte sessionsmodel. En slettet UI-variabel er ikke nok.
2. 2. Stop aktive dataveje. Afmeld realtidslyttere, stop forespørgsler og baggrundssynkronisering, og sørg for at gamle async-svar ikke kan skrive data tilbage efter logout.
3. 3. Håndtér lokale kladder. Synkronisér, eksportér eller bed om en tydelig beslutning, før ikke-gemte ændringer fjernes.
4. 4. Ryd den rigtige brugers data. Fjern bruger- og virksomhedsspecifikke poster fra Web Storage, IndexedDB og appens caches uden at slette nødvendige data for en anden aktiv konto.
5. 5. Nulstil klienttilstanden. Tøm in-memory caches, valgte poster, downloadlinks og fejltilstande, og send brugeren til en side uden følsomt indhold.
6. 6. Synkronisér faner. Afklar hvordan logout og kontoskift opdages i andre åbne faner. De skal stoppe beskyttede kald og skjule den gamle tilstand.

Et konkret bibliotek kan have andre standarder. Firebase Authentication bruger for eksempel som udgangspunkt lokal persistens i webbrowseren, mens session- og hukommelsesbaseret persistens også findes. Kontrollér den faktiske version og opsætning i jeres loginløsning i stedet for at antage, at fanen styrer levetiden.

Brug Clear-Site-Data med præcision

En logout-respons over HTTPS kan bruge HTTP-headerenClear-Site-Datatil at bede browseren fjerne valgte typer data som cache, cookies og storage. Det kan være et nyttigt ekstra sikkerhedsnet, men bør ikke indsættes ukritisk.

• Vælg direktiver efter appens reelle lagring; et globalt wildcard kan fjerne mere end hensigten.
• Kontrollér domæne- og origin-grænser. Cookie-oprydning kan påvirke relaterede subdomæner, mens flere apps på samme origin kan dele lager.
• Test de browsere og enheder, virksomheden understøtter, fordi enkelte dele af headeren kan have forskellig understøttelse.
• Bevar eksplicit oprydning i appen og server-side sessionstilbagekaldelse. Headeren er ikke en erstatning for nogen af delene.

Afprøv en delt enhed og et kontoskift

En god test bruger to konti med tydeligt forskellige data. Kør den i et realistisk browsermiljø og gentag den med både netværk og offline-tilstand.

1. Bruger A logger ind. Åbn følsomme poster, søg, hent en fil, opret en lokal kladde og lad mindst to faner stå åbne.
2. A logger ud. Kontrollér netværksrespons, cookies, localStorage, sessionStorage, IndexedDB, Cache API og aktive service workers.
3. Prøv rester. Brug tilbage- og fremknap, genindlæs, gå offline, åbn et tidligere downloadlink, og genstart browseren.
4. Bruger B logger ind. Ingen data, filtre, kladder, forslag eller realtime-opdateringer fra A må kunne ses eller sendes.
5. Kontrollér serveren. Forsøg et beskyttet API-kald med den gamle session. Det skal afvises, selv hvis en gammel fane stadig har klientkode og data.

Gem testen som en fast releasekontrol, når login, offline-funktion, service worker, cachepolitik eller domæneopsætning ændres.

Typiske fejl

• Logout ændrer kun skærmbilledet: Refresh-token eller server-session virker stadig fra en gammel fane.
• Kun localStorage ryddes: IndexedDB, service-worker-cache og in-memory state indeholder stadig den gamle brugers data.
• Hele origin ryddes uden analyse: En anden app, nødvendig enhedsopsætning eller usynkroniseret kladde forsvinder.
• no-cache læses som “gem ikke”: Svaret kan fortsat lagres og genbruges efter validering.
• Offlinedata mangler ejer: Konto B overtager en kø eller kladde, som blev oprettet af konto A.
• Kun online-flowet testes: Tilbageknap, genstart og offline-visning afslører gamle data efter logout.

Tjekliste til browserlagring og logout

• ☐ Web Storage, IndexedDB, Cache API, HTTP-cache, cookies, auth-SDK og klientcache er kortlagt.
• ☐ Hver lokal datatype har formål, ejer, brugerkontekst, levetid og oprydningshændelse.
• ☐ Sessions-id'er og andre følsomme tokens ligger ikke ukritisk i JavaScript-læsbar lagring.
• ☐ Usynkroniserede kladder har en synlig og testet politik for logout og kontoskift.
• ☐ Følsomme HTTP-svar har en bevidst cachepolitik, og no-cache forveksles ikke med no-store.
• ☐ Logout stopper session, lyttere, baggrundssynkronisering og sene async-svar.
• ☐ Oprydningen er afgrænset, så den ikke rammer andre apps eller den forkerte bruger.
• ☐ Andre åbne faner reagerer på logout og kontoskift.
• ☐ Bruger A → logout → offline/tilbageknap → bruger B er testet på understøttede browsere.
• ☐ Den gamle server-session afvises, selv hvis browseroprydningen fejler.

Relaterede guides

• Sikkert login, sessioner og kontogendannelse
• Offline data og synkronisering
• PWA, service worker og cache
• XSS og sikkerhedsheaders i webappen

Officielle kilder

Browseradfærd, SDK-standarder og understøttelse ændrer sig. Kontrollér altid den konkrete browsermatrix, auth-udbyder og service-worker-opsætning, før en logout-politik bruges i produktion.

• MDN: Web Storage API
• MDN: Browserlagring, kvoter og automatisk sletning
• MDN: HTTP-cache og Cache-Control
• MDN: Clear-Site-Data-headeren
• OWASP: HTML5 Security Cheat Sheet
• OWASP: Session Management Cheat Sheet
• Firebase: Authentication State Persistence