🔒 HTTP-sikkerhetsheadere for WordPress: komplett oppsettguide

WordPress-nettstedet ditt kjører, sikkerhetspluginen er installert, men en sjekk på securityheaders.com gir deg en F. Høres det kjent ut?

HTTP-sikkerhetsheadere er et usynlig beskyttelseslag som blir oversett selv etter at man har satt opp en brannmur og tofaktorautentisering. De krever ingen lisensfornyelser, belaster ikke serveren og blokkerer hele klasser av angrep: fra clickjacking til sesjonskapring. Og de tar 10 minutter å legge til.

Nedenfor, steg for steg: hvilke headere du faktisk trenger, hvordan du konfigurerer dem via.htaccess, functions.php eller en plugin, og hvordan du verifiserer at beskyttelsen fungerer, ikke bare er oppført.

💡 Rask oversikt:

• Sjekk nettstedets nåværende headere via securityheaders.com eller Mozilla Observatory for å se det virkelige bildet
• Aktiver et grunnleggende sett med 4-5 headere: X-Content-Type-Options, X-Frame-Options, HSTS, Referrer-Policy, Permissions-Policy
• Velg metode: et par linjer i.htaccess (Apache/LiteSpeed), en kodesnutt i functions.php eller pluginen Headers Security Advanced & HSTS WP
• La CSP ligge til senere: den er vanskelig å konfigurere og ødelegger Gutenberg hvis det gjøres uten testing
• Etter implementering, sjekk på nytt: en A+-score er oppnåelig på 10 minutter

Hva HTTP-sikkerhetsheadere er

Når en nettleser ber om en side, sender webserveren tilbake mer enn bare HTML-kode. Hvert HTTP-svar inneholder tjenestefelt, headere. Noen håndterer mellomlagring og innholdstype, og noen håndterer sikkerhet.

Nettleseren leser sikkerhetsheadere før den i det hele tatt begynner å rendre siden. Hvis serveren sier «jeg forbyr innbygging av dette nettstedet i rammer», vil ikke nettleseren gjøre det, selv om sidekoden inneholder en <iframe>. Hvis serveren sier «bruk kun HTTPS i ett år», husker nettleseren det og vil ikke gå til HTTP-versjonen, selv om brukeren skriver den inn manuelt.

Ingen JavaScript, ingen plugin, ingen brannmur påvirker dette. Dette er på protokollnivå. Det er nettopp derfor headere er en separat, uavhengig forsvarslinje.

Hvorfor et WordPress-nettsted trenger dette

Sikkerhetspluginer som Wordfence eller Solid Security lukker sårbarheter på applikasjonsnivå: brute force, injeksjoner, ondsinnede opplastinger. HTTP-headere fungerer ett nivå høyere: de beskytter selve kommunikasjonskanalen mellom serveren og den besøkende.

Her er hva riktig konfigurerte headere blokkerer:

• Clickjacking. En angriper bygger inn nettstedet ditt i en gjennomsiktig ramme oppå sin egen og fanger opp brukerklikk. Blokkert av headeren X-Frame-Options eller frame-ancestors-direktivet i CSP.

• MIME-sniffing. Nettleseren prøver å «gjette» filtypen og kan kjøre et opplastet bilde som JavaScript. Blokkert av X-Content-Type-Options: nosniff.

• Sesjonskapring. En angriper på et åpent Wi-Fi-nettverk endrer serversvaret og stjeler innloggingsinformasjonskapsler. HSTS forbyr nettleseren fra å få tilgang til HTTP-versjonen av nettstedet.

• Referer-lekkasje. Når man følger en ekstern lenke, ser målnettstedet hvilken side brukeren kom fra, inkludert URL-en med parametere. Referrer-Policy begrenser dette.

• Uautorisert enhetstilgang. En nettside ber om mikrofon, kamera eller geolokasjon uten at brukeren vet det. Permissions-Policy blokkerer slike forespørsler på nettlesernivå.

CSP legger til et nytt lag: du definerer eksplisitt hvilke domener som kan laste inn skript, stiler og fonter. Selv om ondsinnet kode kommer inn i databasen, vil ikke nettleseren kjøre den fordi kilden ikke er i tillatelseslisten. Men CSP krever forsiktighet: én liten feil, så slutter Gutenberg-redigeringsverktøyet å fungere.

Viktige HTTP-sikkerhetsheadere: hva de inneholder og hvorfor

Nedenfor er headerne det er verdt å konfigurere på ethvert WordPress-nettsted. For hver enkelt spesifiserer vi: hvilket angrep den beskytter mot, anbefalt verdi og hvor ting kan gå i stykker.

X-Content-Type-Options

Den enkleste og tryggeste å konfigurere. Den eneste gyldige verdien er nosniff. Nettleseren slutter å «gjette» MIME-typen til en fil basert på innholdet og stoler kun på typen serveren sendte i Content-Type-headeren.

Uten denne headeren kan nettleseren behandle et brukeropplastet bilde som et skript og kjøre det, et klassisk scenario for filopplastingsangrep.

Anbefalt verdi: nosniff

Risiko for feil: minimal. Problemer er bare mulig hvis serveren leverer filer med feil Content-Type, men det er et separat problem som er verdt å fikse i stedet for å maskere.

X-Frame-Options

Kontrollerer om nettstedet ditt kan bygges inn i en <frame>, <iframe> eller <object> på et annet nettsted.

To hovedverdier:

• DENY, et fullstendig forbud mot innbygging. Maksimal beskyttelse.
• SAMEORIGIN, innbygging tillates kun fra samme domene. Nødvendig hvis du selv bruker rammer for dine egne sider (for eksempel forhåndsvisning i administrasjonspanelet).

For de fleste WordPress-nettsteder fungerer SAMEORIGIN. Hvis du vet sikkert at ingen rammer brukes, sett DENY.

Anbefalt verdi: SAMEORIGIN

Risiko for feil: noen utvidelser bruker iframes for forhåndsvisninger. Hvis noe slutter å vises i administrasjonspanelet etter at du har aktivert DENY, bytt til SAMEORIGIN.

Strict-Transport-Security (HSTS)

Forteller nettleseren: «for de neste N sekundene, bruk kun HTTPS til dette domenet.» Beskytter mot nedgraderingsangrep og kapring av informasjonskapsler på åpne nettverk.

Nøkkelparameteren er max-age. Det anbefales å starte med en liten verdi (en dag eller en uke) og, etter verifisering, øke den til et år.

Den valgfrie parameteren includeSubDomains utvider regelen til alle underdomener, viktig hvis du har flere og bruker et CDN.

Parameteren preload legger til nettstedet i nettlesernes globale HSTS-liste: Chrome, Firefox og Safari vil kun bruke HTTPS til domenet ditt selv før den første forespørselen. Send inn en søknad via hstspreload.org.

Anbefalt verdi: max-age=31536000; includeSubDomains

Risiko for feil: hvis du aktiverer HSTS og SSL-sertifikatet utløper, vil ikke brukere få tilgang til nettstedet i det hele tatt. Hold øye med automatisk fornyelse av sertifikater.

Referrer-Policy

Styrer hvilken informasjon om kildesiden nettleseren sender når den følger en lenke til et annet nettsted.

Hovedverdier, fra strengeste til mest tillatende:

• no-referrer, ingenting sendes i det hele tatt.
• strict-origin-when-cross-origin, til et annet domene sendes kun domenet (ingen sti eller parametere); til ditt eget sendes hele URL-en. Den optimale balansen mellom personvern og analyse.
• strict-origin, alltid kun domenet, ingen sti.

Hvis du ikke vil at målnettsteder skal vite hvor brukeren kom fra i det hele tatt, sett no-referrer. Men husk: du vil miste henvisningstrafikk i din egen analyse.

Anbefalt verdi: strict-origin-when-cross-origin

Risiko for feil: minimal. Noen tredjepartstjenester kan kreve en referrer for å fungere (for eksempel betalingsgatewayer med kildeverifisering). Du kan spore slike tilfeller via nettleserkonsollen.

Permissions-Policy

Tidligere kalt Feature-Policy. Begrenser nettsidens tilgang til «maskinvare»-API-er i nettleseren: mikrofon, kamera, geolokasjon, USB, betalings-API-er og så videre.

Format: название-фичи=(разрешённый-источник). For eksempel:

1
Permissions-Policy: camera=(), microphone=(), geolocation=(self)

Dette eksempelet blokkerer fullstendig tilgang til kamera og mikrofon for alle kilder, og tillater geolokasjon kun for selve nettstedet (self).

Fullstendig liste over funksjoner på MDN. For et WordPress-nettsted uten videochatter og PWA-funksjoner er det nok å blokkere kamera, mikrofon og geolokasjon; resten er valgfritt.

Anbefalt verdi: avhenger av nettstedets funksjonalitet. Minimum: camera=(), microphone=(), geolocation=(self).

Risiko for feil: hvis nettstedet har videosamtaler, PWA eller WebUSB-funksjonalitet, sjekk hvilke funksjoner det trenger og ikke blokker dem.

Content-Security-Policy (CSP)

Den kraftigste og den farligste headeren å konfigurere. Definerer en tillatelsesliste over kilder for skript, stiler, fonter, bilder, rammer og andre ressurser.

Eksempel på en minimal policy for WordPress:

1
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;
2

*Hvorfor unsafe-inline og unsafe-eval:* WordPress, Gutenberg og dusinvis av utvidelser genererer innebygde skript og bruker eval(). Uten disse direktivene vil administrasjonspanelet rett og slett ikke fungere. Dette er prisen for kompatibilitet.

Anbefaling: ikke aktiver CSP først. Konfigurer de andre 5 headerne først. Implementer kun CSP hvis du har ressurser til testing og overvåking; start med Content-Security-Policy-Report-Only-modus og samle bruddslogger i et par uker før du bytter til håndhevingsmodus.

Risiko for feil: høy. En feil i CSP kan fullstendig ødelegge frontend og administrasjonspanel. Test alltid i et staging-miljø eller via Report-Only.

Hvordan sjekke nettstedets nåværende headere

Før konfigurering, en revisjon. Tre verktøy, fra enkle til detaljerte:

• securityheaders.com, skriv inn URL-en og få en poengsum fra A+ til F med en oversikt for hver header. Gratis, ingen registrering.

• Mozilla Observatory, en mer detaljert revisjon: evaluerer ikke bare headere, men også TLS-innstillinger, informasjonskapselattributter, CORS og andre aspekter. Også gratis.

• Chrome DevTools, åpne Nettverk-fanen, velg en hvilken som helst forespørsel til nettstedet ditt, og se på Response Headers-delen. En rask måte å sjekke om endringer «tok» etter redigering av.htaccess.

Sjekk nettstedet ditt akkurat nå. Hvis poengsummen er under B, har du ikke engang grunnleggende headere, og en tredjedel av punktene nedenfor setter du opp på 5 minutter.

Måter å konfigurere HTTP-headere i WordPress

Tre veier, fra manuell til automatisk. Velg basert på situasjonen din.

Metode 1: Via.htaccess (Apache/LiteSpeed)

Den raskeste metoden for nettsteder på Apache eller LiteSpeed. Legg til i .htaccess-filen i nettstedets rot (før # BEGIN WordPress):

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

<IfModule mod_headers.c>-omslaget sikrer at nettstedet ikke krasjer med en 500-feil hvis mod_headers-modulen ikke er aktivert. Hvis du vet sikkert at den er aktiv, kan du utelate det.

Etter lagring, kjør i terminalen (hvis du har WP-CLI) eller bare åpne nettstedet og sjekk headerne via securityheaders.com. Endringer i .htaccess trer i kraft umiddelbart; ingen omstart av serveren er nødvendig.

Metode 2: Via functions.php (Nginx / universell)

Fungerer uavhengig av webserver, egnet for både Nginx og Apache. Legg til i functions.php i ditt child theme eller via Code Snippets-pluginen:

1
function sdstudio_add_security_headers() {
2
    header( 'X-Content-Type-Options: nosniff' );
3
    header( 'X-Frame-Options: SAMEORIGIN' );
4
    header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains' );
5
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
6
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=(self)' );
7
}
8
add_action( 'send_headers', 'sdstudio_add_security_headers' );

send_headers-hooken utløses før WordPress begynner å sende innhold, så headere sendes ut i den aller første serverresponsen.

For Nginx er denne metoden å foretrekke fremfor å grave i serverkonfigurasjonen (spesielt på shared hosting, hvor tilgang til nginx.conf ofte er utilgjengelig). Ulempen: headere fungerer bare for PHP-forespørsler som går gjennom WordPress. Statiske filer (bilder, CSS, JS) serveres direkte av Nginx og vil ikke få headerne. De krever konfigurasjon på servernivå.

Metode 3: Via pluginen headers security advanced & hsts wp

Hvis du ikke vil røre kode, bruk en dedikert plugin. Headers Security Advanced & HSTS WP samler alle sikkerhetsheadere i ett grensesnitt og aktiverer dem med én enkelt knapp.

Pluginen setter forhåndsdefinerte verdier for alle nøkkelheadere umiddelbart etter aktivering: X-Content-Type-Options, X-Frame-Options, HSTS, CSP, Referrer-Policy, Permissions-Policy, og flere ekstra (CORP, COOP, COEP). Hver header kan deaktiveres eller tilpasses dine behov.

Fordelen med denne tilnærmingen: pluginen er ikke avhengig av webserveren og fungerer identisk på Apache, Nginx, LiteSpeed og IIS. Ved deaktivering returnerer den nettstedets konfigurasjon til sin opprinnelige tilstand.

Alternativ: Redirection

Redirection-pluginen er kjent som en redirect manager, men den kan også legge til HTTP-headere. Etter installasjon og grunnleggende oppsett, gå til Site → Headers-seksjonen; grensesnittet lar deg spesifisere alle «header: verdi»-par.

Dette alternativet fungerer hvis du allerede har Redirection installert for lenkehåndtering og ikke vil legge til en ny plugin. Men en dedikert header-plugin gir mer kontroll og forhåndsdefinerte verdier.

I videoen, en visuell demonstrasjon av konfigurering av headere via Headers Security Advanced-pluginen: fra installasjon til verifisering av resultatet på securityheaders.com.

⁉️🤔 Vanlige spørsmål

Hva om nettstedet bryter sammen etter aktivering av headere?

Sjekk først Content-Security-Policy-headeren: den forårsaker det store flertallet av sammenbrudd. Deaktiver CSP (eller bytt den til Report-Only-modus) og sjekk nettstedet igjen. En 500-feil etter redigering av.htaccess: sjekk syntaksen for et ekstra mellomrom, ulukkede anførselstegn eller en manglende mod_headers-modul. Via FTP, endre navn på.htaccess, nettstedet vil komme til live igjen, og du kan rolig finne feilen.

I 9 av 10 tilfeller er problemet spesifikt CSP, ikke de andre headerne. X-Content-Type-Options, X-Frame-Options, HSTS og Referrer-Policy kan fysisk ikke ødelegge nettstedet; de påvirker ikke rendering eller PHP-logikk. Start alltid med disse.

Er en plugin obligatorisk, eller kan det gjøres via kode?

Det kan og bør gjøres via kode hvis du vet hvordan du redigerer functions.php eller.htaccess. Å sette headere direkte gjennom serverkonfigurasjon fungerer raskere enn en plugin, uten noe PHP-lag imellom. Men en plugin er mer praktisk for de som ikke vil røre kode og gir et visuelt grensesnitt med forhåndsinnstillinger for hver header.

På våre testsider bruker vi begge tilnærminger: på produksjon,.htaccess (færre feilkilder); på klientsider hvor hostingen ikke tillater redigering av konfigurasjonen, pluginen. Resultatet på securityheaders.com er identisk: A+ i begge tilfeller.

Må jeg konfigurere CSP hvis nettstedet er på WordPress?

For de fleste nettsteder, nei. CSP på WordPress krever unsafe-inline og unsafe-eval for at Gutenberg og dusinvis av pluginer skal fungere, noe som reduserer den beskyttende effekten til symbolsk. En fullverdig CSP gir mening på høytrafikkprosjekter med en dedikert sikkerhetsspesialist som vil analysere hver violasjonsrapport. For alle andre gir de 5 grunnleggende headerne brorparten av praktisk beskyttelse.

Hvordan bekrefter jeg at headerne fungerer etter installasjon?

Åpne nettstedet i en nettleser, start DevTools (F12) → Network-fanen → klikk på den første forespørselen til ditt domene → Response Headers-seksjonen. Hvis du ser de tilføyde headerne, fungerer alt. For automatisert verifisering, bruk securityheaders.com: det viser ikke bare tilstedeværelse, men også korrekthet av verdier, pluss en endelig poengsum fra A+ til F.

Hva om hostingen ikke tillater redigering av.htaccess og det ikke er tilgang til functions.php?

Installer Headers Security Advanced & HSTS WP via WordPress-administrasjonspanelet. Pluginen injiserer headere på PHP-nivå og krever ikke redigering av serverfiler. Dette fungerer på enhver hosting hvor WordPress kjører, fra billig shared til Managed WordPress.

Påvirker HTTP-headere nettstedets hastighet?

Praktisk talt ikke. Headere er et par dusin byte med tekst i serverresponsen. De utfører ingen beregninger, gjør ingen databasespørringer og belaster ikke CPU-en. Forsinkelsen de legger til måles i mikrosekunder. Det eneste unntaket er CSP med en kompleks tillatelsesliste over hundrevis av domener: nettleseren bruker tid på å analysere den, men selv da overstiger ikke påvirkningen på renderingshastigheten et par millisekunder.

Hva du bør sette og hvor du skal starte

HTTP-sikkerhetsheadere er ikke en engangs «sett det og glem det»-handling. De er en grunnlinje som bør være på hvert nettsted som standard, som et SSL-sertifikat.

Planen for i dag:

• Sjekk nettstedet ditt på securityheaders.com. Hvis poengsummen er D eller F, har du ikke engang X-Content-Type-Options.

• Legg til de 5 grunnleggende headerne ved hjelp av en av de tre metodene ovenfor. Hvis nettstedet er på Apache, via.htaccess (30 sekunder). Nginx uten konfigurasjonstilgang, via functions.php (2 minutter). Hvis du ikke vil røre kode, Headers Security Advanced-pluginen (3 minutter inkludert installasjon).

• Sjekk på nytt nettstedet. Poengsummen bør stige til A eller A+.

• Legg CSP til side. Kom tilbake til det når de grunnleggende headerne har fungert i en måned uten problemer og du har tid til testing via Report-Only.

Én time, og WordPress-nettstedet ditt får et forsvarslag som det store flertallet av nettsteder på internett mangler. Start med en sjekk akkurat nå.