Lektion 28 — Cookies och sessioner

HTTP själv har inget minne. Varje request är fristående — servern vet inte att du som klickade på "Mina sidor" är samma person som loggade in för fem sekunder sen. Cookies löste det. Cookies är också vad som gör att du kan bli stulen.

01Cookie-flödet, från start till slut

När du loggar in på en sajt händer detta i fyra steg:

1. Du: POST /login (med användarnamn + lösenord)
2. Servern: 200 OK
Set-Cookie: session=A8F3...; Path=/
3. Du går till /profil →
GET /profil + Cookie: session=A8F3...
4. Servern: "Aha, det är ada igen." Visar din profil.

Cookien session=A8F3... är som ett armband på en festival. När du checkar in får du det, och sen behöver du bara visa det vid varje dörr. Sajten behöver inte fråga om ditt lösenord igen — armbandet räcker.

02Vad finns i en cookie?

Bara text. Ett namn och ett värde:

Set-Cookie: session=A8F3J9K2L4M5N6P7

Värdet är ofta ett slumpat ID. Servern har en intern tabell som översätter det till "användare 42, inloggad sen klockan 14:22". Du ser bara den slumpade strängen — den i sig avslöjar inget om dig.

03Prova själv — sätt en cookie live

Skriv ett namn och ett värde. Du ser exakt vad Set-Cookie-headern skulle se ut, och cookien sätts faktiskt på den här sidan så du kan inspektera den i F12 → Application → Cookies. Den försvinner när du stänger fliken.

Namn Värde

Set-Cookie-header (vad servern skickar)

skriv ovan

cookies som ligger på den här sidan just nu

tryck "sätt cookie" ovan

Lagring: din browser, lokalt Försvinner: när du stänger fliken

04Varför det här är säkerhetskritiskt

Om någon kommer åt din session-cookie kan de logga in som du — utan ditt lösenord. Det är som att stjäla festivalarmbandet: vakterna släpper in vem som bär det, inte vem du är.

Tre saker som kan stjäla din cookie: en sårbar sajt (XSS, lektion 24), en man-i-mitten på osäkert WiFi (lektion 23), eller en illvillig browser-extension. Försvaret är cookie-attribut — som vi tar i djupare-spåret.

05Vad det betyder för dig

När du loggar ut på en sajt — vad händer egentligen? Servern säger åt browsern att glömma cookien (Set-Cookie: session=; Max-Age=0) och slänger sessions-ID:t från sin tabell. Båda sidor måste glömma. Om du bara stänger fliken: cookien finns ofta kvar — kolla nästa lektion (29) för moderna alternativ utan denna fallgrop.

Cookies infördes 1994 av Netscape som en hack för att lägga till state ovanpå ett statelöst protokoll. Hacket blev permanent. Idag är cookie-attributen — SameSite, HttpOnly, Secure — vad som gör skillnaden mellan en säker session och en stulen identitet.

01Anatomy of Set-Cookie

En komplett Set-Cookie kan se ut så här:

Set-Cookie: session=A8F3...; Path=/; Domain=säkerkoll.se;
Max-Age=86400; Secure; HttpOnly; SameSite=Lax

Varje attribut har en specifik säkerhetsroll:

Path — vilka URL:er får browsern skicka cookien till.
Domain — vilken domän äger cookien. Domain=säkerkoll.se ger även subdomäner åtkomst.
Max-Age / Expires — hur länge cookien gäller. Utan båda = session-cookie (försvinner när browsern stängs).
Secure — skickas bara över HTTPS. Aldrig HTTP.
HttpOnly — osynlig för JavaScript. document.cookie kan inte läsa den. Stoppar XSS från att stjäla session.
SameSite — den viktigaste i CSRF-försvaret. Tre värden: Strict, Lax, None.

02SameSite — den moderna nyckelförsvararen

SameSite styr om cookien skickas vid cross-site requests — alltså requests som initieras från en annan sajt:

Strict — cookien skickas aldrig från en annan sajt. Strängast, kan bryta legitim cross-site UX (t.ex. om någon delar en länk till en post på Facebook och du klickar — du behöver logga in igen).
Lax — modern default. Skickas vid top-level GET-navigationer från andra sajter, men inte vid cross-site POST eller iframe-laddningar.
None — skickas alltid. Måste kombineras med Secure. Används för iframes och cross-site embeds (t.ex. analytics-pixels).

Sedan Chrome 80 (2020) är default Lax om SameSite inte anges. Det dödade en stor klass CSRF-attacker över en natt.

03CSRF: när cookies blir vapnet mot dig

Cross-Site Request Forgery utnyttjar att browsern automatiskt skickar cookies med varje request — även om requestet initieras från en illvillig sajt:

Du är inloggad på bank.se i en flik.
Du öppnar evil.com i en annan flik. Den har:
<form action="bank.se/överför" method="POST"> ... </form>
Skriptet submittar formuläret. Browsern skickar med dina bank-cookies.
Banken ser ett legitimt request från dig.

Försvar: SameSite=Lax/Strict, plus CSRF-tokens (slumpat värde i ett dolt fält som måste matcha sessionen), plus Origin-header-verifiering.

04Sessions: server-side vs stateless

Server-side sessions — cookien innehåller bara ett ID. Sessions-data (vem du är, behörigheter, varukorg) ligger på servern. Kan revokeras direkt. Skalas svårare över flera servrar (behöver delad lagring som Redis).
Stateless tokens — hela sessionsdatan ligger i token (JWT). Servern lagrar inget. Lätt att skala, svårare att revokera enskilda sessioner.

Hybrid är vanligast: stateless tokens för API-trafik, server-side sessions för admin-UI där revokering måste vara omedelbar.

05Prova själv — sätt cookies med olika attribut

Konfigurera en cookie och se exakt vad Set-Cookie-headern blir. Bocka i attributen och se hur browser-beteendet förändras.

Namn Värde

Secure HttpOnly SameSite: Lax

resulterande Set-Cookie-header

väntar...

vad detta faktiskt skyddar mot

väntar...

HttpOnly stoppar: XSS-stöld Secure kräver: HTTPS SameSite skyddar mot: CSRF

06Checklista — en säker cookie 2026

Secure — alltid, även i utvecklingsmiljö när möjligt
HttpOnly — för alla auth/session-cookies. Bara opt-out om JS måste läsa.
SameSite=Lax som minimum. Strict för känsliga sajter (banker, admin).
__Host-prefix — cookies som börjar med __Host- kräver Secure, Path=/, och ingen Domain. Hindrar subdomain-spoofing.
Max-Age kort för auth — typ 24 timmar för session, längre bara för "remember me" med separata regler

Cookies — hur sajter minns dig.

01Cookie-flödet, från start till slut

02Vad finns i en cookie?

03Prova själv — sätt en cookie live

04Varför det här är säkerhetskritiskt

05Vad det betyder för dig

01Anatomy of Set-Cookie

02SameSite — den moderna nyckelförsvararen

03CSRF: när cookies blir vapnet mot dig

04Sessions: server-side vs stateless

05Prova själv — sätt cookies med olika attribut

06Checklista — en säker cookie 2026

Snabb-koll — tre frågor

Lektion 29 — JWT, JSON Web Tokens