Ett HTTP-request är som ett brev med ett gäng små etiketter på utsidan: vem skickar, vad vill du ha, vilket språk pratar du. Etiketterna heter headers, och de berättar mer om dig än du tror.
01Vad är en header?
Headers är nyckel-värde-rader som följer med varje HTTP-request och varje svar. Strukturen är enkel:
Nyckel: värde
Det är allt. Webbläsaren staplar tio till tjugo av dessa rader på varje request. Vissa är obligatoriska (Host), vissa är artighet (Accept-Language), vissa är säkerhetsrelaterade (Authorization, Cookie). Servern svarar med sina egna headers tillbaka.
02De viktigaste request-headers
Här är vad din webbläsare faktiskt skickar varje gång:
- Host — vilken sajt du vill nå. Obligatorisk.
- User-Agent — din browser och ditt operativsystem ("Chrome 130 på Windows 11"). Sajter använder det för att veta vad de pratar med.
- Accept — vilka filtyper du klarar av att ta emot (
text/html, image/webp...).
- Accept-Language — vilka språk du föredrar (
sv-SE, en;q=0.8). Det är därför Google visar svenska åt dig.
- Referer — vilken sida du kom från. Felstavat sedan 1996. Kan läcka information.
- Cookie — alla cookies sajten har satt på dig. Bär din inloggning.
- Authorization — bär inloggningstoken eller user/pass när du loggar in via API.
03Prova själv — vad din browser avslöjar
Nedan ser du vad din webbläsare just nu säger om dig. Allt detta skickas i en eller annan header varje gång du besöker en sajt. Inget av det lämnar din dator här — vi läser bara navigator-objektet lokalt.
Vad din webbläsare avslöjar just nu
läser...
Källa: navigator + screen + Intl
Lokalt: 0 nätverksanrop
Det här är delar av det som kallas browser fingerprint. I kombination med IP-adress, fonts, plugins och rendering-skillnader blir det ofta unikt nog att identifiera dig — utan en enda cookie.
04Servern svarar också med headers
När servern skickar tillbaka svaret har det också headers, som styr hur browsern beter sig:
- Content-Type — vilken sorts data svaret är (
text/html, application/json...).
- Set-Cookie — "spara den här cookien åt mig till nästa gång".
- Cache-Control — får browsern spara svaret? Hur länge?
- Location — vid en redirect (3xx) säger den vart du ska istället.
- Content-Security-Policy — säkerhetsregler. Mer om dem i djupare-spåret.
05Vad det betyder för dig
Headers är inte detaljer — de är där all webbsäkerhet faktiskt sker. Lösenord skickas i Authorization. Inloggning bärs av Cookie. Skydd mot att din sajt körs på fel domän kommer från Content-Security-Policy. Att förstå headers är att förstå hur webben faktiskt fungerar.
Nästa lektion (27) tittar specifikt på HTTP Basic Auth — den enklaste formen av inloggning, och varför den nästan aldrig används utan HTTPS.
Headers är där webbsäkerheten faktiskt bor. Alla auth-mekanismer, alla skyddslager mot XSS, clickjacking, MIME-sniffing och CSRF, all CORS-policy — allt är headers. Här är de viktigaste, indelade i request, response, och de moderna säkerhetsheaders som varje sajt borde sätta.
01Request headers du måste känna till
Utöver de vanliga (Host, User-Agent, Accept, Accept-Language) är dessa kritiska för säkerhet:
- Authorization — bär autentisering. Formatet är
Schema värde — t.ex. Basic dXNlcjpwYXNz eller Bearer eyJhbGc....
- Cookie — alla cookies för domänen, sammanfogade som
k1=v1; k2=v2.
- Referer — varifrån klicket kom. Sajter använder den för CSRF-skydd och analytics. Kan trimmas med
Referrer-Policy.
- Origin — vilken origin (scheme + host + port) som initierade requestet. Används av CORS och CSRF-skydd.
- X-Forwarded-For — om requestet kommit genom proxy/CDN, vilken IP klienten har. Aldrig lita på utan att verifiera vem som satte den.
02Response headers — de gamla
Servern svarar med headers som påverkar både hur browsern renderar och hur säker sidan är:
- Content-Type — kritisk.
text/html renderas, application/json renderas inte. Fel content-type kan göra en JSON-endpoint sårbar för XSS.
- Set-Cookie — sätter cookies, ofta med attribut:
HttpOnly (otillgänglig för JS), Secure (bara över HTTPS), SameSite (Lax/Strict/None — CSRF-skydd).
- Cache-Control —
no-store för känsliga sidor, annars kan de fastna i mellanproxys eller browser-cache.
- Location — vid 3xx. Open redirect-sårbarheter uppstår när Location byggs av användarinput.
03Säkerhetsheaders du borde sätta
Den moderna webben har lagt till en stor familj headers vars enda syfte är försvar:
- Strict-Transport-Security (HSTS) — "tvinga HTTPS i 1 år framöver". Skyddar mot downgrade-attacker.
- Content-Security-Policy (CSP) — vilka scripts/styles/images/forms får browsern köra från vilka källor. Det starkaste XSS-försvaret som finns.
- X-Frame-Options / frame-ancestors — hindrar att din sajt embeddas i en
<iframe> på en bedragar-sajt (clickjacking).
- X-Content-Type-Options: nosniff — hindrar browsern från att gissa filtyp och köra något som JS som inte är JS.
- Referrer-Policy — hur mycket av Referer-headern som läcker.
strict-origin-when-cross-origin är en bra default.
- Permissions-Policy — vilka browser-API:er (kamera, mikrofon, GPS, USB) sidan får använda.
04De nya isolation-headers
2020 introducerades trippeln som tillsammans isolerar din sajt från andra origin på samma process — vilket är vad du behöver för att kunna använda SharedArrayBuffer och vara säker mot Spectre-attacker:
- Cross-Origin-Opener-Policy (COOP) —
same-origin hindrar andra fönster från att referera till ditt.
- Cross-Origin-Embedder-Policy (COEP) —
require-corp kräver att alla resurser opt-in:ar.
- Cross-Origin-Resource-Policy (CORP) — vilka origin får ladda min resurs.
05Prova själv — full browser-fingerprint
Här är vad din webbläsare exponerar via headers och JS. Det är mycket. Det är därför integritets-rörelsen tar fingerprinting på allvar.
Din browser, hela paketet
läser...
Notera: Tor Browser normaliserar allt detta — alla användare ser likadana ut.
06Hur du inspekterar headers i verkligheten
Tre verktyg som varje säkerhetsperson måste kunna:
curl -I https://example.se — skickar HEAD-request, skriver ut bara response headers.curl -v https://example.se — verbose, visar både request och response headers.- F12 → Network i browsern — klicka på vilken som helst request, se alla headers in och ut.
Säkerkoll har en publik headers-check på /url-koll — klistra in en URL och se vilka säkerhetsheaders sajten faktiskt sätter.