Säkerhetsheaders: 5 headers varje svensk webbplats behöver

HTTP-säkerhetsheaders blockerar hela kategorier av attacker. De kostar ingenting att implementera och tar minuter att konfigurera. Ändå saknar majoriteten av svenska webbplatser minst två av de fem headrar som behandlas här.

Om du driver en webbplats som hanterar personuppgifter kräver GDPR artikel 32 att du implementerar "lämpliga tekniska åtgärder" för att skydda dem. NIS2 artikel 21(2)(e) går längre och kräver säkerhet i nätverks- och informationssystem för verksamheter som omfattas. Saknade säkerhetsheaders är en mätbar brist i båda fallen.

Varför HTTP-säkerhetsheaders spelar roll

Varje gång en webbläsare laddar din webbplats skickar din server HTTP-svarsheaders tillsammans med sidinnehållet. Säkerhetsheaders instruerar webbläsaren att aktivera specifika skydd: blockera skript som inte borde köras, vägra att låta angripare rama in din webbplats och tvinga krypterade anslutningar.

Utan dessa headers förlitar du dig helt på webbläsarens standardbeteende. Standardinställningarna är tillåtande. Angripare vet detta.

1. Strict-Transport-Security (HSTS)

HSTS tvingar webbläsare att använda HTTPS för alla anslutningar till din domän. När webbläsaren väl har sett denna header vägrar den att ladda din webbplats via vanlig HTTP, även om en användare skriver http:// eller klickar på ett gammalt bokmärke.

Detta förhindrar SSL-stripping-attacker, där en angripare avlyssnar den initiala HTTP-förfrågan och nedgraderar anslutningen till okrypterad trafik. Utan HSTS är varje första besök på din webbplats sårbart för denna avlyssning.

• Rekommenderat värde: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
• max-age=63072000 säger åt webbläsaren att komma ihåg policyn i två år
• includeSubDomains tillämpar policyn på alla underdomäner, så angripare inte kan utnyttja en underdomän utan HSTS
• preload registrerar din domän i HSTS-preload-listan, inbyggd i Chrome, Firefox, Safari och Edge. Detta eliminerar även sårbarheten vid första besöket

Utan HSTS kan en angripare på samma nätverk (publikt Wi-Fi, komprometterad router) avlyssna och läsa trafik som borde vara krypterad. För webbplatser som hanterar personuppgifter är detta en direkt risk enligt GDPR artikel 32.

2. Content-Security-Policy (CSP)

CSP ger dig mest kontroll av alla säkerhetsheaders. Den talar om för webbläsaren exakt vilka innehållskällor som får laddas på din sida: skript, stilmallar, bilder, typsnitt och ramar. Allt som inte uttryckligen tillåts blockeras.

Detta är det primära försvaret mot cross-site scripting (XSS). Om en angripare injicerar en skadlig script-tagg på din sida förhindrar CSP att den körs eftersom skriptets ursprung inte finns i din tillåtna lista.

• default-src 'self' — tillåt bara resurser från din egen domän som standard
• script-src 'self' — begränsa JavaScript till din domän (lägg till specifika CDN-domäner vid behov)
• style-src 'self' — begränsa stilmallar till din domän
• img-src 'self' data: — tillåt bilder från din domän och data-URI:er
• frame-ancestors 'self' — förhindra andra webbplatser från att rama in dina sidor (ersätter X-Frame-Options)

Börja med en restriktiv policy och lägg till undantag efter behov. En tillåtande CSP (script-src 'unsafe-inline' 'unsafe-eval') motverkar hela syftet. Om din webbplats använder inline-skript, flytta dem till externa filer eller använd CSP-nonces.

3. X-Frame-Options

X-Frame-Options förhindrar att din webbplats bäddas in i en iframe på en annan webbplats. Detta blockerar clickjacking-attacker, där en angripare lägger transparenta element ovanpå din webbplats för att lura användare att klicka på knappar de inte kan se.

En clickjacking-attack mot en bankportal, adminpanel eller samtyckeformulär kan leda till obehöriga åtgärder. Användaren tror att de klickar på angriparens sida, men de klickar i verkligheten på knappar på din inbäddade webbplats.

• DENY — ingen webbplats kan rama in dina sidor, inklusive din egen domän
• SAMEORIGIN — bara din egen domän kan rama in dina sidor
• Rekommenderat: SAMEORIGIN om du inte har något legitimt behov av iframes

CSP:s frame-ancestors-direktiv är den moderna ersättaren för X-Frame-Options och erbjuder mer detaljerad kontroll. X-Frame-Options är dock fortfarande viktigt för äldre webbläsare som inte stöder CSP. Sätt båda för fullständig täckning.

4. X-Content-Type-Options

Denna header med ett enda värde förhindrar MIME-typgissning. Webbläsare försöker ibland "gissa" en fils innehållstyp genom att undersöka dess innehåll istället för att lita på Content-Type-headern. Angripare utnyttjar detta genom att ladda upp filer som ser ut som en typ men körs som en annan.

Till exempel laddar en angripare upp en fil som ser ut som en bild men som faktiskt innehåller JavaScript. Utan denna header kan webbläsaren komma att köra den.

• Enda giltiga värdet: X-Content-Type-Options: nosniff
• Tvingar webbläsaren att respektera den deklarerade Content-Type
• Förhindrar skriptkörning från felaktiga MIME-svar
• Noll konfigurationskomplexitet. Ställ in och glöm

Det finns ingen anledning att inte sätta denna header. Den har ett värde, inga kompatibilitetsproblem och ingen prestandapåverkan.

5. Referrer-Policy

Referer-headern (ja, den ursprungliga HTTP-specifikationen stavade den fel) talar om för målwebbplatsen vilken URL användaren kom från. Utan en Referrer-Policy kan din webbplats läcka fullständiga URL:er (frågeparametrar, interna sökvägar, sessionstoken) till varje extern länk och resurs som din sida laddar.

För webbplatser som hanterar personuppgifter är detta en integritetsläcka. URL-parametrar kan innehålla sökfrågor, användar-ID:n eller andra identifierare som utgör personuppgifter enligt GDPR.

• strict-origin-when-cross-origin — skickar bara ursprunget (domänen) till andra webbplatser, men fullständig URL för same-origin-förfrågningar. Bästa balansen mellan funktionalitet och integritet.
• no-referrer — skickar ingen referensinformation alls. Maximal integritet men bryter analys och vissa integrationer.
• Undvik: unsafe-url skickar fullständig URL till alla destinationer, inklusive HTTP-webbplatser

Rekommendation: strict-origin-when-cross-origin för de flesta webbplatser. Använd no-referrer om du hanterar känslig data i URL-sökvägar (vårdportaler, finansiella instrumentpaneler).

Hur Vakteye skannar efter saknade headers

Vakteyes headers-skanningsuppgift kontrollerar 15+ säkerhetsheaders vid varje skanning. Varje saknad header flaggas som ett fynd med FIRM-konfidens, kopplat till GDPR artikel 32 och NIS2 artikel 21(2)(e). Rapporten innehåller åtgärdsrekommendationer med det exakta headervärde du bör ställa in.

Skanningsresultaten visar inte bara vilka headers som saknas, utan vilka attacker varje lucka möjliggör och vilka lagkrav den bryter mot. Fynden inkluderar färdiga konfigurationssnippets för vanliga webbservrar och ramverk.

Lagkrav: GDPR och NIS2

GDPR artikel 32 kräver att personuppgiftsansvariga och personuppgiftsbiträden implementerar "lämpliga tekniska och organisatoriska åtgärder" för att säkerställa en säkerhetsnivå som är lämplig i förhållande till risken. Säkerhetsheaders är ett skolboksexempel: gratis, brett stödda och effektiva mot välkända attackvektorer.

NIS2 artikel 21(2)(e) adresserar specifikt nätverks- och informationssystemssäkerhet, inklusive policyer för användning av kryptografi och kryptering. HSTS och CSP faller båda direkt under detta krav.

IMY har hänvisat till saknade tekniska säkerhetsåtgärder i flera tillsynsbeslut. När grundläggande, branschstandardmässiga skydd saknas är det svårt att hävda att dina åtgärder var "lämpliga."