Typer av cookies: en komplett teknisk guide

Alla cookies är inte likadana. Cookietypen avgör hur länge den finns kvar, vem som kan läsa den, hur säkert den överförs och – vilket är avgörande – om den kräver användarens samtycke. Att förstå dessa skillnader är väsentligt för såväl efterlevnad som implementering.

Sessionscookies kontra beständiga cookies

Den mest grundläggande skillnaden är hur länge en cookie varar.

Sessionscookies

En sessionscookie finns bara under den tid som en webbläsarsession pågår. Den har inget Expires- eller Max-Age-attribut. När användaren stänger sin webbläsare raderas cookien.

Set-Cookie: cart_id=xyz789; Path=/; Secure; HttpOnly

Sessionscookies används vanligtvis för:

• Att upprätthålla inloggningsstatus under ett besök
• Innehåll i varukorgen
• CSRF-skyddstokens
• Formulärdata i flera steg

Eftersom sessionscookies inte finns kvar är de i allmänhet mindre inkräktande ur ett integritetsperspektiv. De kräver dock fortfarande samtycke om de inte är strikt nödvändiga för den tjänst som användaren har begärt.

Beständiga cookies

En beständig cookie har ett uttryckligt utgångsdatum. Den överlever omstarter av webbläsaren och finns kvar på användarens enhet tills den löper ut eller raderas manuellt.

Set-Cookie: preferences_lang=en; Path=/; Max-Age=31536000; Secure

Den här cookien finns kvar i ett år (31 536 000 sekunder). Vanliga användningsområden är bland annat:

• Funktion för att komma ihåg inloggning
• Inställningar för språk och tema
• Analysidentifierare (Google Analytics-cookies finns kvar i upp till 2 år)
• Annonsspårning (vissa annonscookies finns kvar i 13 månader eller längre)

Beständiga cookies granskas hårdare enligt integritetslagstiftningen. CNIL (Frankrikes dataskyddsmyndighet) har rekommenderat en maximal livslängd för cookies på 13 månader, och samtycket måste även förnyas minst var 13:e månad.

Förstapartscookies kontra tredjepartscookies

Den här skillnaden är central i integritetsdebatten och påverkar direkt kraven på samtycke.

Förstapartscookies

En förstapartscookie sätts av den domän som användaren faktiskt besöker. Om du besöker example.com är alla cookies som sätts av example.com förstapartscookies.

Förstapartscookies används för grundläggande webbplatsfunktioner: sessioner, inställningar och analys som webbplatsoperatören själv kör. De kan bara läsas av den domän som satte dem.

Exempel: Du besöker shop.example.com. Servern sätter en cookie som heter session_id. Denna cookie skickas endast till shop.example.com och dess underdomäner. Ingen annan webbplats kan komma åt den.

Tredjepartscookies

En tredjepartscookie sätts av en annan domän än den som användaren besöker. När example.com läser in ett annonsskript från ads.tracker.com och det skriptet sätter en cookie under domänen tracker.com är det en tredjepartscookie.

Det är så här spårning mellan webbplatser fungerar. Cookien från tracker.com skickas med varje begäran till tracker.com, oavsett vilken webbplats som utlöste begäran. Om skript från tracker.com är inbäddade på 10 000 webbplatser kan de observera samma användare över alla 10 000 webbplatser.

Tredjepartscookies är det primära målet för både regulatorisk tillsyn och begränsningar på webbläsarnivå:

• Safari har blockerat tredjepartscookies som standard sedan 2020 (ITP)
• Firefox blockerar kända tredjepartsspårare som standard (ETP)
• Chrome fasar ut tredjepartscookies genom sitt Privacy Sandbox-initiativ
• Regulatoriska tillsynsåtgärder inriktar sig till övervägande del på tredjepartsspårningscookies

Secure-cookies

En cookie med attributet Secure skickas bara över HTTPS-anslutningar. Den kommer aldrig att överföras via okrypterad HTTP.

Set-Cookie: auth_token=secret123; Secure

Detta hindrar en angripare som utför en man-in-the-middle-attack från att avlyssna cookien på en osäker anslutning. Alla cookies som innehåller känslig information – sessionsidentifierare, autentiseringstokens, personuppgifter – bör alltid märkas med Secure.

Ur ett efterlevnadsperspektiv kan en underlåtenhet att använda Secure-flaggan på känsliga cookies betraktas som en underlåtenhet att vidta lämpliga tekniska åtgärder enligt artikel 32 i GDPR (säkerhet i behandlingen).

HttpOnly-cookies

En cookie med attributet HttpOnly kan inte kommas åt av JavaScript via document.cookie. Den skickas endast med HTTP-begäranden till servern.

Set-Cookie: session_id=abc123; HttpOnly

Detta är en kritisk säkerhetsåtgärd. Cross-site scripting-attacker (XSS) försöker ofta stjäla cookies genom att injicera JavaScript som läser document.cookie. Flaggan HttpOnly förhindrar denna angreppsvektor helt.

Sessionscookies och autentiseringscookies bör nästan alltid vara HttpOnly. Cookies som behöver läsas av JavaScript på klientsidan (till exempel inställningscookies som påverkar användargränssnittet) kan inte vara HttpOnly.

SameSite-cookies

Attributet SameSite styr om en cookie skickas med begäranden mellan olika webbplatser. Det introducerades för att motverka cross-site request forgery-attacker (CSRF) och för att ge webbplatser mer kontroll över hur cookies beter sig mellan webbplatser.

SameSite=Strict

Cookien skickas bara med begäranden som kommer från samma webbplats. Om en användare klickar på en länk på other.com som går till your-site.com kommer cookien inte att skickas med den ursprungliga begäran.

Detta är den säkraste inställningen men kan störa legitim funktionalitet. Om en användare exempelvis klickar på en länk till din webbplats från ett e-postmeddelande skickas inte deras sessionscookie, och de skulle framstå som utloggade.

SameSite=Lax

Cookien skickas med navigeringar på toppnivå (klick på en länk) men inte med delbegäranden mellan webbplatser (inläsning av bilder, ramar eller AJAX-begäranden från en annan webbplats). Detta är standardvärdet i moderna webbläsare om inget SameSite-attribut anges.

Lax ger en rimlig balans mellan säkerhet och användbarhet. Det hindrar tredjepartswebbplatser från att utlösa autentiserade åtgärder på din webbplats samtidigt som normal länknavigering fortfarande fungerar.

SameSite=None

Cookien skickas med alla begäranden, inklusive begäranden mellan webbplatser. Detta krävs för att tredjepartscookies ska fungera. En cookie som sätts med SameSite=None måste även ha attributet Secure.

Set-Cookie: tracking_id=xyz; SameSite=None; Secure

Alla cookies som behöver fungera i ett sammanhang mellan webbplatser (inbäddade widgetar, tredjepartsautentisering, spårning mellan webbplatser) måste använda SameSite=None. Detta blir allt mer relevant i takt med att webbläsare skärper sina standardpolicyer för cookies.

Zombiecookies och superkakor

Dessa är värda att nämna eftersom de representerar försök att kringgå integritetskontroller:

• Zombiecookies är cookies som återskapar sig själva efter att de har raderats. De fungerar vanligtvis genom att lagra samma identifierare i flera lagringsmekanismer (cookies, localStorage, IndexedDB, Flash LSO:er) och använda den som överlever för att återskapa de andra. Detta betraktas allmänt som vilseledande och har varit föremål för tillsynsåtgärder.
• Superkakor är spårningsmekanismer som verkar på en nivå under vanliga cookies – till exempel headerinjektion på ISP-nivå (Verizons UIDH) eller HSTS-baserad fingeravtrycksidentifiering. De är extremt svåra för användare att kontrollera eller radera.

Både zombiecookies och superkakor är uppenbart oförenliga med kraven i GDPR och ePrivacy. Att använda dem skulle utgöra en överträdelse av principerna om transparens, laglighet och uppgiftsminimering.

Jämförelsetabell

Typ	Livslängd	Omfattning	Krävs vanligtvis samtycke?	Viktiga användningsområden
Session	Endast webbläsarsession	Förstapart	Endast om icke-nödvändig	Inloggningsstatus, varukorg, CSRF-tokens
Beständig (förstapart)	Dagar till år	Förstapart	Vanligtvis ja	Inställningar, analys, kom-ihåg-mig
Beständig (tredjepart)	Dagar till år	Mellan webbplatser	Nästan alltid ja	Annonsering, retargeting, sociala widgetar
Secure	Varierar	Endast HTTPS	Beror på syfte	Alla känsliga cookies
HttpOnly	Varierar	Endast serversidan	Beror på syfte	Sessions-ID:n, autentiseringstokens
SameSite=Strict	Varierar	Endast samma webbplats	Beror på syfte	CSRF-känsliga operationer
SameSite=Lax	Varierar	Samma webbplats + navigering på toppnivå	Beror på syfte	Allmän sessionshantering
SameSite=None	Varierar	Alla sammanhang (kräver Secure)	Nästan alltid ja	Tredjepartsinbäddningar, autentisering mellan webbplatser

Vad detta innebär för efterlevnaden

Cookietypen påverkar direkt dina skyldigheter kring efterlevnad:

1. Förstaparts sessionscookies som är strikt nödvändiga (inloggningssessioner, varukorgar, CSRF-tokens) är undantagna från kraven på samtycke enligt ePrivacy artikel 5.3.
2. Förstaparts beständiga cookies för analys, inställningar eller funktionalitet kräver i allmänhet samtycke – även om vissa dataskyddsmyndigheter tillåter begränsade undantag för förstapartsanalys under specifika förutsättningar.
3. Tredjepartscookies av alla slag kräver nästan alltid uttryckligt förhandssamtycke. Det finns mycket få legitima undantag.
4. Säkerhetsattribut (Secure, HttpOnly, SameSite) ändrar inte kraven på samtycke, men att använda dem visar på god säkerhetspraxis – vilket i sig är ett krav enligt GDPR.

Att veta exakt vilka cookies din webbplats sätter – och vilken typ var och en är – är grunden för alla efterlevnadsprogram. Passiros skanner identifierar och klassificerar automatiskt varje cookie på din webbplats, inklusive tredjepartscookies som sätts av inbäddade skript som du kanske inte ens känner till.

Nu när vi förstår de olika typerna ska vi titta på hur cookies organiseras i samtyckeskategorier – klassificeringssystemet som avgör hur de visas i din cookiebanner.