Sikkerhedsheadere: HSTS, nosniff og vejen til CSP

Kort svar: Sikkerhedsheadere er instruktioner, som serveren sender med hvert svar, og som får browseren til at håndhæve beskyttelse hos den besøgende. Fire af dem giver værdi på stort set alle WordPress-sites og kan sættes med lav risiko: HSTS (tving https), X-Content-Type-Options (stop MIME-sniffing), Referrer-Policy (begræns udsivende URL-data) og X-Frame-Options eller CSP frame-ancestors (stop clickjacking). Content-Security-Policy er den stærkeste, men kræver forarbejde: start i Report-Only, og håndhæv først, når rapporterne er tomme for legitime fejl.

Fagligt gennemgået: 2. oktober 2026

Sikkerhedsheadere er usædvanlige i sikkerhedsverdenen: de er gratis, usynlige for besøgende og kræver næsten ingen vedligeholdelse, når de først er sat rigtigt. De beskytter mod en anden klasse angreb end firewalls og stærke adgangskoder, nemlig dem, der udnytter browseren: nedgradering til http, indlejring af dit site i en fremmed side og indsprøjtede scripts.

Guiden tager de sikre headere først, viser de tre måder at sætte dem på, og gør CSP til et overskueligt projekt i stedet for en risiko.

Før du ændrer noget: Tag en kopi af din nuværende .htaccess (eller notér dine eksisterende regler i Cloudflare eller sikkerhedspluginnet), og sæt kun HSTS, når https virker fejlfrit på hele domænet. HSTS huskes af browserne i den periode, du angiver, og kan ikke trækkes tilbage med et klik.

1. Tjek din status først

Start med at se, hvad dit site sender i dag. Kommandoen henter kun headerne og filtrerer de relevante fra:

curl -sI https://dinside.dk/ | grep -i -E "strict-transport|x-content-type|referrer-policy|x-frame|content-security|permissions-policy"

Kør den også mod en underside og mod en statisk fil (fx et billede i /wp-content/uploads/), fordi headere sat via PHP ikke rammer statiske filer. Foretrækker du en browser, viser fanen Netværk i udviklerværktøjerne de samme headere, og onlinetests som MDN HTTP Observatory giver en samlet vurdering. De fleste WordPress-sites starter med få eller ingen af headerne. Hostingmiljøet sætter typisk nogle få, og resten er dit valg.

2. Sæt de fire sikre headere

Header	Beskytter mod	Anbefalet værdi
Strict-Transport-Security (HSTS)	Nedgradering til http og cookie-tyveri på usikre net	max-age=31536000; includeSubDomains (krav: hele sitet og alle subdomæner kører https)
X-Content-Type-Options	MIME-sniffing – filer fortolket som noget andet, end de er	nosniff
Referrer-Policy	Fulde URL’er (med parametre) udsivet til tredjeparter	strict-origin-when-cross-origin
X-Frame-Options	Clickjacking – dit site indlejret i en fremmed ramme	SAMEORIGIN

Alle fire kan sættes på et almindeligt WordPress-site uden synlige bivirkninger, med én fælde: HSTS er et langtidsløfte til browserne. Når en browser har set headeren, nægter den at bruge http til domænet, indtil max-age udløber. Sæt den derfor først, når https er stabilt overalt, også på subdomæner, hvis du bruger includeSubDomains. Har du et gammelt subdomæne uden certifikat, bliver det utilgængeligt. Få certifikatfornyelsen automatiseret først – se guiden om udløbne SSL-certifikater.

En forsigtig indkøring er at starte med en kort max-age (fx 300 sekunder), tjekke at alt virker, og derefter hæve til et år. Direktivet preload og tilmelding til browsernes HSTS-preload-liste er et ekstra skridt, som er svært at fortryde. Tag det kun, hvis du er sikker på, at domænet og alle subdomæner skal køre https permanent.

X-Frame-Options eller frame-ancestors?

X-Frame-Options er den ældre header, og CSP-direktivet frame-ancestors 'self' er den moderne afløser med samme formål. Moderne browsere følger frame-ancestors, hvis begge er sat. Det er ufarligt at sende begge, så længe de siger det samme. Skal dit site kunne indlejres hos en partner, angiver du partnerens domæne i frame-ancestors i stedet for at slå beskyttelsen fra.

Headere, du kan springe over

X-XSS-Protection ses stadig i gamle guides, men moderne browsere har fjernet det filter, headeren styrede. Den giver ingen beskyttelse i dag og kan udelades. Det samme gælder Expect-CT, som er udfaset. Brug tiden på CSP i stedet.

3. Vælg ét sted at sætte dem

Der er tre lige gyldige veje. Vælg én, så headerne ikke dubleres. To forskellige værdier af samme header giver uforudsigelig adfærd og er den klassiske følgefejl.

Serverlaget: .htaccess på LiteSpeed eller Apache

Det mest robuste sted, fordi reglerne gælder alle svar, også statiske filer. Læg blokken øverst i .htaccess, uden for de sektioner, som WordPress og cache-plugins selv skriver (mellem # BEGIN og # END), så de ikke overskrives. Se også guiden om at gendanne .htaccess, hvis filen går i stykker.

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Permissions-Policy-linjen er valgfri. Den slår kamera, mikrofon og geolokation fra for sitet og eventuelle indlejrede rammer. Fjern den del, dit site faktisk bruger, fx geolokation i en butiksfinder.

Kanten: Cloudflare eller andet CDN

Ligger sitet bag Cloudflare, kan headere sættes centralt med regler, der ændrer svar-headere, og Cloudflare har også en færdig indstilling, der tilføjer et sæt grundlæggende sikkerhedsheadere. Menupunkterne flytter sig jævnligt, så søg efter “response header” i Cloudflares egen dokumentation. Fordelen er, at reglerne følger domænet, selv hvis du skifter hosting. Ulempen er, at du skal huske dem, hvis du en dag fjerner Cloudflare. Læs mere i guiden til Cloudflare-indstillinger.

WordPress: plugin eller lille kodestump

Flere sikkerhedsplugins har et header-modul. Alternativt kan du sætte dem med en lille kodestump i et must-use-plugin:

<?php
add_action( 'send_headers', function () {
    header( 'X-Content-Type-Options: nosniff' );
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
    header( 'X-Frame-Options: SAMEORIGIN' );
} );

PHP-vejen har to begrænsninger: den rammer kun svar, som WordPress selv genererer (ikke billeder, CSS og JavaScript), og svar fra en sidecache kan sendes uden om koden afhængigt af opsætningen. Til HSTS er serverlaget eller kanten derfor det bedre valg. Kan du ikke selv redigere serverkonfigurationen, så spørg din hostingudbyders support, om de kan sætte headerne på serverniveau.

4. Byg CSP i Report-Only først

Content-Security-Policy er en positivliste over, hvor scripts, styles, billeder, fonte og rammer må komme fra. Den kan stoppe indsprøjtede scripts, selv hvis de sniger sig ind i siden. Prisen er præcision: WordPress-temaer, plugins og tredjepartsscripts henter fra mange kilder, og en for stram politik knækker sitet synligt – typisk betalingsvinduer, indlejrede videoer, chatwidgets og analyseværktøjer.

Arbejdsgangen er derfor:

1. Send politikken som Content-Security-Policy-Report-Only. Browseren rapporterer overtrædelser i konsollen (og til en rapport-adresse, hvis du har en), men blokerer intet.
2. Klik de vigtige flows igennem: forside, artikel, kontaktformular, kurv, checkout og betaling. Notér hver blokeret kilde.
3. Udvid listen med de kilder, der er legitime, og fjern de scripts, du alligevel ikke bruger.
4. Lad politikken køre i Report-Only et par uger, så sjældne sider og kampagner også kommer med.
5. Skift til den håndhævende header Content-Security-Policy, når rapporterne kun viser støj.

Et startpunkt kan se sådan ud, men skal tilpasses dit site:

Header always set Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'"

'unsafe-inline' er med, fordi mange WordPress-temaer og plugins bruger inline-scripts. Det svækker beskyttelsen mod scripts, men politikken giver stadig værdi via object-src, base-uri, frame-ancestors og kontrol med eksterne kilder. At komme helt af med 'unsafe-inline' kræver nonces eller hashes og er et udviklerprojekt. Kombineret med en oprydning i tredjepartsscripts bliver listen både kortere og mere ærlig.

5. Verificér og dokumentér

Opsætningen er bekræftet, når:

• curl viser hver header præcis én gang med den ønskede værdi – på forsiden, en underside og en statisk fil.
• Sitet fungerer uændret: indlejrede videoer, betalingsvinduer, formularer og wp-admin er dem, der typisk mærker X-Frame-Options og CSP.
• Browserkonsollen ikke viser nye blokeringer på de vigtige sider.
• Onlinetestens vurdering er løftet.

Notér til sidst i driftsdokumentationen, hvor headerne sættes (server, kant eller plugin). Så ved den næste, der fejlsøger, hvor der skal kigges, og dubletfælden forbliver lukket. Går noget galt, ruller du tilbage ved at fjerne den nye blok og lægge den gemte .htaccess tilbage. Undtagelsen er HSTS, som browserne husker – derfor den korte max-age under indkøringen.

Læs også

• Hub: WordPress sikkerhed og backup
• Mixed content efter SSL
• wp-config-hærdning: saltnøgler, file edit og debug
• Tredjepartsscripts, der koster hastighed
• LiteSpeed og .htaccess: reglerne, pluginnet skriver
• WordPress hosting hos Hostious – LiteSpeed, gratis SSL via Let’s Encrypt og dansk support døgnet rundt

Ofte stillede spørgsmål om sikkerhedsheadere

Kan headerne ødelægge mit site?

De fire sikre gør det sjældent, fordi de håndhæver ting, et sundt site allerede gør. Undtagelsen er HSTS på et domæne med subdomæner uden gyldigt certifikat. CSP kan derimod blokere legitime ressourcer, hvis den håndhæves uden en Report-Only-fase.

Hjælper headerne på SEO?

Ikke direkte som rankingsignal. HSTS understøtter en fejlfri https-oplevelse, og et site, der ikke kan indlejres i fremmede sider, beskytter brand og brugere. Regn det som hærdning, ikke SEO.

Hvad med Permissions-Policy og de andre nye?

Permissions-Policy slår browserfunktioner som kamera, mikrofon og geolokation fra og er et fint tillæg på sites, der ikke bruger dem. Risikoen er lav og gevinsten lille, men reel. Tag den med i samme omgang som de fire sikre.

Hvorfor står en header to gange i svaret?

Fordi den sættes flere steder, typisk både i .htaccess og i et plugin eller hos Cloudflare. Find de steder, hvor headeren sættes, og behold kun ét. Notér valget i driftsdokumentationen, så det ikke sker igen.