# Informasjonskapsel ## Hva det er En informasjonskapsel, på engelsk HTTP cookie og i daglig tale ofte bare cookie, er et kort navn og en verdi som en webserver sender til nettleseren i en header i svaret, og som nettleseren sender tilbake med de senere forespørslene sine til den samme serveren. Informasjonskapsler er måten HTTP, en protokoll som møter hver forespørsel som en fremmed, får en hukommelse på: en innlogging som overlever neste klikk, en handlekurv som fortsatt er full i kassen, et språk som velges én gang og blir husket. Serveren setter hver informasjonskapsel med sin egen `Set-Cookie`-header, og nettleseren sender tilbake alle som gjelder, samlet i én `Cookie`-header. Her er de tre første linjene et svar, og resten er en senere forespørsel fra den samme nettleseren: ```http HTTP/1.1 200 OK Set-Cookie: __Host-sid=4f2c9a71e0b8; Path=/; Secure; HttpOnly; SameSite=Lax Set-Cookie: lang=da; Max-Age=31536000; Path=/ GET /account/ HTTP/1.1 Host: shop.example Cookie: __Host-sid=4f2c9a71e0b8; lang=da ``` Alt etter det første semikolonet er et attributt, en instruks om hvor lenge informasjonskapselen skal tas vare på og hvor den skal sendes. `Expires` eller `Max-Age` setter en øvre levetid. Er ingen av dem satt, varer informasjonskapselen til nettleseren bestemmer at økten er over. `Domain` utvider den til et helt domene og underdomenene, og uten dette attributtet går den bare tilbake til verten som satte den. `Path` snevrer den inn til en del av nettstedet. `Secure` holder den unna ukrypterte forbindelser, `HttpOnly` skjuler den for skript som leser `document.cookie`, og `SameSite` avgjør om den blir med på forespørsler som et annet nettsted setter i gang. Returreisen bærer bare navn og verdier, så serveren kan ikke se av den når en informasjonskapsel utløper, om den ble satt med `Secure`, eller hvem som skrev den sist. Reglene står i RFC 6265, publisert i 2011. Revisjonen, kjent som rfc6265bis, legger til `SameSite`, navneprefiksene `__Secure-` og `__Host-` og et krav om at nettlesere begrenser hver levetid til høyst 400 dager. I skrivende stund er revisjonen godkjent og venter i køen hos RFC Editor på å erstatte RFC 6265. ## Hvorfor det er viktig En informasjonskapsel er som regel det eneste som skiller en innlogget forespørsel fra en anonym. Etter en innlogging er øktidentifikatoren i informasjonskapselen selve personen, slik serveren ser det: den som viser den fram, får kontoen, og ingen spør etter passordet. Det meste som går galt med informasjonskapsler, handler om at noen andre leser, kopierer eller bruker en. Nettleseren gjør det siste av disse lett. Den legger ved informasjonskapsler på hver forespørsel de passer til, uansett hvem som startet forespørselen. Et skjema på et annet nettsted som poster til en nettbutikk, kommer fram med den besøkendes informasjonskapsler, og serveren ser en forespørsel fra en innlogget person. RFC 6265 kaller dette _ambient authority_, en fullmakt som følger med av seg selv, og navngir angrepene den inviterer til: forfalskede forespørsler på tvers av nettsteder (_cross-site request forgery_) og _confused deputy_, der en mellommann lures til å bruke sin egen fullmakt for noen andre. Informasjonskapsler er også det eldste sporingsverktøyet på nettet. Et skript som er bygd inn på tusenvis av nettsteder, kan sette en informasjonskapsel fra sitt eget domene, og nettleseren sender den tilbake fra hvert av disse nettstedene, så ett selskap kan stille opp en persons besøk på tvers av dem alle. Revisjonen beskriver denne bruken av tredjeparts informasjonskapsler, påpeker at de fleste nettlesere nå blokkerer eller partisjonerer dem, og anbefaler en policy som er så restriktiv som kompatibiliteten tillater. Loven følger lagringen og ikke teknologien. I EU tillater artikkel 5 nr. 3 i kommunikasjonsverndirektivet, ofte kalt ePrivacy-direktivet, at et nettsted lagrer informasjon på en besøkendes enhet, eller leser det som er lagret der, bare med samtykke gitt etter klar og fullstendig informasjon. Unntakene er lagring som bare brukes til å overføre en kommunikasjon, og lagring som er strengt nødvendig for en tjeneste den besøkende uttrykkelig har bedt om. Den artikkelen er opphavet til samtykkebannerne, og den nevner aldri informasjonskapsler ved navn. Retningslinjene fra Det europeiske personvernrådet (EDPB) om det tekniske virkeområdet bruker den også på sporingspiksler og sporingslenker. I Norge er artikkelen gjennomført i ekomloven § 3-15. Datatilsynet beskriver bestemmelsen som teknologinøytral: den gjelder lagring av og tilgang til alle slags opplysninger i kommunikasjonsutstyret, enten det er personopplysninger eller ikke. Den nye ekomloven trådte i kraft 1. januar 2025, og samtykket må nå være gyldig etter personvernforordningen (GDPR), blant annet frivillig, informert, gitt gjennom en aktiv handling og like lett å trekke tilbake som å gi. Før det var det for eksempel nok at standardinnstillingene i nettleseren tillot informasjonskapsler. Datatilsynet og Nasjonal kommunikasjonsmyndighet (Nkom) deler tilsynet med bestemmelsen. ## Slik ser det ut i praksis Dette nettstedet setter ingen. [Siden om informasjonskapsler](/nb/cookies/) forklarer hvorfor: det finnes ingen kontoer, ingen handlekurv og ingenting å følge en besøkende med, så det finnes ikke noe samtykkebanner, fordi det ikke er noe å samtykke til. Siden lister også de andre stedene et nettsted kan legge igjen noe, fra `localStorage` til en service worker, og sier at ingen av dem brukes heller. Å klare seg uten informasjonskapsler endrer hvordan et nettsted lærer om leserne sine. [Lesertellingen ut fra tilgangsloggen alene](/nb/portfolio/measured-thirteen-addresses-from-the-access-log-alone-166/) måler lesingen uten informasjonskapsel, skript eller piksel, fra webserverens egen logg, og fjerner `Cookie`-headeren fra hver linje idet linjen skrives, sammen med authorization-headeren. Resultatet er grovt med vilje: unike besøkende og en besøkendes vei gjennom nettstedet er utenfor rekkevidde, og siden skriver de grensene ved siden av tallene. Der en applikasjon trenger en informasjonskapsel, er det nyttige spørsmålet hva den blir betrodd. På en plattform der én person handler på vegne av flere organisasjoner, [holdes den aktive organisasjonen i nettleseren, og en informasjonskapsel på serversiden speiler den](/nb/portfolio/designed-an-organization-context-switching-system-with-client-59/), slik at sider som renderes på serveren, viser den samme konteksten. Tilgangen avgjøres likevel av noe annet enn de to kopiene: serveren kontrollerer autorisasjonen ved hver forespørsel, så den som redigerer verdien, endrer hva den egne skjermen viser, og ikke noe mer. Det er den trygge formen for enhver informasjonskapsel: verdien kan velge hva som skal vises, og avgjørelsen om hva noen har lov til å gjøre, blir værende på serveren. ## Hvor det går galt **Skript på siden leser økten.** Et skript en angriper har sprøytet inn, kan lese `document.cookie` når `HttpOnly` mangler, og sende øktidentifikatoren hvor som helst. `HttpOnly` tar informasjonskapselen ut av det API-et. Det stopper tyveri, men ikke misbruk: det innsprøytede skriptet kan fortsatt sende forespørsler, og nettleseren legger fortsatt ved informasjonskapselen, så `HttpOnly` står ved siden av en Content Security Policy og erstatter den ikke. **Informasjonskapselen krysser vanlig HTTP.** En informasjonskapsel uten `Secure` går ut på enhver `http://`-forespørsel til verten sin, lesbar for alle på nettverksveien. Etter RFC 6265 vokter `Secure` bare konfidensialiteten, og en angriper på nettverket kan fortsatt overskrive en sikker informasjonskapsel fra en usikret forbindelse. Revisjonen snevrer inn gapet: den ignorerer `Secure`-informasjonskapsler som settes over vanlig HTTP, og avviser en informasjonskapsel fra vanlig HTTP som ville lagt seg over en sikker. **Et søsterunderdomene setter informasjonskapselen.** `Domain=example.com` sender en informasjonskapsel til hver vert under det domenet, og hver av disse vertene kan sette en informasjonskapsel for hele domenet, som hovednettstedet da leser som sin egen. `Path` er heller ingen sikkerhetsgrense. Prefikset `__Host-` svarer på dette: en nettleser godtar en slik informasjonskapsel bare når den er `Secure`, har `Path=/` og står uten `Domain`, noe som låser den til den ene verten som satte den. **Et annet nettsted starter forespørselen.** `SameSite=Strict` holder informasjonskapselen til forespørsler fra det samme nettstedet, `Lax` legger til navigasjon på toppnivå med trygge metoder, som å følge en lenke, og `None` sender den overalt og blir ignorert med mindre informasjonskapselen også er `Secure`. Revisjonen behandler en informasjonskapsel uten `SameSite` omtrent som `Lax`, og en server som er avhengig av det, bør si det eksplisitt. Et nettsted er i denne sammenhengen skjemaet i adressen, som `https`, pluss det registrerbare domenet, så `SameSite` gjør ingenting mot et fiendtlig søsterunderdomene. **Serveren tror på verdien.** Alt i en informasjonskapsel kan redigeres av personen som har nettleseren den ligger i. RFC 6265 anbefaler at servere krypterer og signerer innholdet i informasjonskapsler, og advarer om at en informasjonskapsel fortsatt kan spilles av på nytt. Det mer robuste mønsteret er en tilfeldig øktidentifikator som peker på tilstand lagret på serveren og byttes ut ved innlogging. Da betyr en identifikator som en angriper plantet på forhånd, ingenting etterpå, og det er nettopp øktfikseringen (_session fixation_) RFC-en advarer mot. **Nettleseren gir slipp på den.** En utløpsdato er et maksimum. Nettlesere kaster ut informasjonskapsler for å holde seg innenfor grensene sine, og en angriper kan presse informasjonskapsler ut ved å sette mange egne. Servere bør derfor ikke regne med at nettlesere tar vare på informasjonskapsler. Å slette en har også en felle: en `Set-Cookie` med en utløpsdato i fortiden fjerner informasjonskapselen bare når `Path` og `Domain` stemmer med verdiene den ble opprettet med. ## Les mer - [RFC 6265: HTTP State Management Mechanism](https://www.rfc-editor.org/rfc/rfc6265) — standarden for `Set-Cookie` og `Cookie`, med reglene for attributtene og en sikkerhetsdel om ambient authority, svak integritet og øktidentifikatorer. - [Cookies: HTTP State Management Mechanism (rfc6265bis)](https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/) — den godkjente revisjonen, med `SameSite`, prefiksene `__Secure-` og `__Host-`, taket på 400 dager og en del om tredjeparts informasjonskapsler. - [Directive 2002/58/EC, consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02002L0058-20091219) — kommunikasjonsverndirektivet slik det ble endret i 2009, med artikkel 5 nr. 3 om lagring og lesing av informasjon på en enhet. - [EDPB Guidelines 2/2023 on the technical scope of Article 5(3)](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en) — hvordan regelen når sporingspiksler, sporingslenker, lokal behandling og andre teknikker ut over informasjonskapsler. - [Bruk av informasjonskapsler (cookies)](https://www.datatilsynet.no/personvern-pa-ulike-omrader/internett-og-apper/cookies/) — Datatilsynets oversikt over ekomloven § 3-15: samtykke etter personvernforordningen, de to unntakene og hvordan tilsynet er delt med Nkom.