Browsercache, cookies og gemte sessioner som spor

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

Browserhistorikken er ikke det eneste sted, en browser husker, hvad der er foregået. Cachen gemmer kopier af hentede sider, billeder og data. Cookies viser, hvilke domæner der har sat oplysninger hos brugeren, og hvornår. Gemte sessioner viser, hvilke faner der var åbne, og hvad der var navigeret til i dem. Sporene kan overleve, når historikken er ryddet, og de kan vise indhold, ikke kun adresser. De skal dog bruges med omtanke: Cookies og sessionsdata kan give adgang til andres konti, og de må kun dokumenteres, aldrig bruges.

Historikdatabaserne, deres placering og tidsformater er beskrevet i Browserhistorik som bevis. Denne artikel går videre til de øvrige kilder i browserprofilen.

Cachen

Når en browser henter en ressource, gemmer den ofte en kopi sammen med serverens svarheadere, så ressourcen kan genbruges. Cachen kan derfor indeholde:

billeder, scripts, stylesheets og data i JSON fra besøgte sider,
adressen, ressourcen blev hentet fra,
serverens headere, fx Date, Last-Modified, Content-Type og cachingregler,
tidspunkter for, hvornår posten blev oprettet eller senest brugt.

Formatet varierer. Chromium-browsere som Chrome og Edge har to cacheformater: blokfiler med en indeksfil og samlede datafiler, og den såkaldte simple cache med en fil pr. post. Hvilket format der bruges, afhænger af platform og version, så det skal aflæses i den konkrete profil. Firefox har en cachemappe med en fil pr. post og en indeksfil. Safari bruger en database og en mappestruktur, der også har skiftet mellem versioner.

Ud over den almindelige HTTP-cache har mange webapps deres egen lagring: Cache Storage fra service workers, IndexedDB og Local Storage. Webmail, chat og dokumenttjenester kan her gemme kopier af beskeder og dokumentlister. Formatet er beskrevet i Plist, LevelDB og andre app-formater.

Hvad cachen kan vise

Cachen kan vise, at en ressource er hentet til maskinen, og i nogle tilfælde hvad indholdet var. Et billede fra et opslag, en profilside eller et dokumentvisningsbillede kan ligge i cachen, selvom siden er lukket og historikken slettet. Serverens Date-header er sat af serveren og er derfor en uafhængig tidsangivelse for, hvornår svaret blev sendt.

Begrænsningerne er væsentlige:

Mange ressourcer hentes automatisk, fx reklamer, forhåndsvisninger og indhold på sider, der kun blev åbnet kort.
Cachen har en størrelsesgrænse og ryddes løbende, så fravær siger intet.
Indhold kan være komprimeret eller delt i flere poster, og dynamiske sider gemmes ofte slet ikke.

Cookies

Cookies gemmes i en SQLite-database i profilen. For hver cookie registreres blandt andet domæne, navn, sti, oprettelsestidspunkt, senest brugt, udløb og flag for sikkerhed. I Chromium er selve værdien krypteret med en nøgle, der er bundet til brugeren og styresystemet: på Windows via DPAPI og på macOS via nøgleringen. På Windows har Chrome siden version 127 desuden app-bundet kryptering, der binder nøglen til browseren selv.

Til en undersøgelse er værdien sjældent nødvendig. Det, der er relevant, er normalt:

at der findes en cookie fra et bestemt domæne,
hvornår den er oprettet og senest brugt,
hvilken profil og hvilken brugerkonto på maskinen den ligger under.

Det kan understøtte, at maskinen har haft kontakt med en tjeneste i et bestemt tidsrum, fx en privat cloudtjeneste eller en konkurrents portal. Det viser ikke, hvad der blev gjort.

Gemte sessioner

Browsere gemmer den aktuelle session, så faner kan genåbnes efter en genstart eller et nedbrud. Chromium har en mappe med sessions- og fanefiler, og Firefox gemmer sessionen i en komprimeret JSON-fil. Indholdet kan omfatte:

åbne vinduer og faner med adresser og titler,
navigationshistorikken i hver fane, så man kan se, hvor brugeren kom fra,
lukkede faner og vinduer,
i nogle tilfælde formulardata.

Sessionsfiler kan vise aktivitet, der ikke længere fremgår af historikken, og de kan sætte flere besøg i sammenhæng.

Dokumentation, ikke genbrug

Cookies og sessionsdata kan indeholde loginsessioner. En kopi af dem kan i princippet give adgang til en konto, som om man var logget ind. Det må aldrig ske i en undersøgelse. At bruge en anden persons session til at åbne en konto kræver lovligt grundlag og er ikke en forensisk metode. Er indholdet af en konto relevant, skal det sikres ad lovlige veje: gennem kontohaver, administratoradgang til virksomhedens egne systemer eller tjenesteudbyderens eksport. Forskellen mellem tokens, sessioner og loginlogs er beskrevet i Sessioner, tokens og loginlogs.

I praksis betyder det:

Dekryptér ikke cookieværdier, medmindre det er nødvendigt og lovligt for et konkret spørgsmål, og beskriv da grundlaget.
Importér aldrig cookies eller sessioner i en browser.
Beskriv cookies og sessioner ved domæne, navn, tidspunkter og placering.

Private data på en arbejdscomputer kræver også omtanke. De juridiske rammer for virksomheder står på Må vi se medarbejderens browserhistorik?, og den tekniske adskillelse er beskrevet i Private data: teknisk adskillelse.

Sikring

Sikr hele browserprofilen, inklusive cache, sessioner, cookies og alle tilhørende journalfiler, helst fra en diskkopi. Mange af filerne er SQLite-databaser med WAL-filer, der skal sikres sammen, se SQLite i forensic. Start ikke browseren på den sikrede maskine. En opstart kan gendanne sessionen, rydde cache og opdatere cookies.

Sammenhæng med andre spor

Cache, cookies og sessioner er stærkest, når de sættes i sammenhæng med andre kilder på samme maskine og hos tjenesten:

Downloads i historikdatabasen og filer i downloadmappen med deres zone-mærkning viser, hvad der faktisk blev gemt.
Programkørsel og logon i Windows viser, hvilken bruger der var logget på, og om browseren kørte i tidsrummet.
Netværkslogs fra virksomhedens proxy, firewall eller DNS kan bekræfte forbindelsen til domænet fra maskinens IP-adresse.
Tjenestens egne logs, fx loginlogs i virksomhedens cloudtjenester, kan vise, at den samme konto var aktiv på samme tidspunkt.

En tidslinje, hvor cache-poster, cookietidspunkter og sessionsfiler står side om side med disse kilder, gør det muligt at skelne mellem et kort, automatisk besøg og en længere, aktiv brug. Uden de andre kilder bør konklusionen holdes på niveauet “der er hentet indhold fra domænet”.

Er historikken slettet, kan det i sig selv være relevant. Sletningen efterlader sig ofte spor i form af tomme eller nyoprettede databaser, mens cache og sessioner fra før sletningen stadig findes. Skeln mellem automatisk oprydning efter browserens indstillinger og en manuel sletning, før der drages konklusioner.

Typiske fejlkilder

Automatisk indhold i cachen forveksles med brugerens bevidste valg.
Synkroniserede data fra en anden enhed forveksles med lokal aktivitet. Sessioner og faner kan synkroniseres mellem enheder.
Tidsformater. Chromium bruger mikrosekunder siden 1601, Firefox mikrosekunder siden 1970, og Safari Apples epoke fra 2001.
Cookies sat af tredjepart fra indlejret indhold på andre sider forveksles med direkte besøg.

Hvad sporene kan og ikke kan bevise

Cache, cookies og sessioner kan vise, at en maskine og en browserprofil har hentet bestemt indhold eller haft kontakt med en tjeneste, og nogle gange hvornår. De kan ikke alene vise, hvem der sad ved maskinen, eller at indholdet blev læst. Det kræver sammenhæng med logon, programkørsel og andre spor.

I rapporten

Angiv profil, sti og hashværdi for hver kilde. Beskriv hvert relevant spor med domæne eller adresse, tidspunkter i UTC og lokal tid samt fortolkning. Skriv udtrykkeligt, at cookies og sessioner kun er dokumenteret og ikke brugt.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Analyse og fortolkning

Læs også: Plist, LevelDB og andre app-formater · Databaser som bevis: transaktionslogs, audittabeller og binlogs

→ Digital forensics-undersøgelse · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik