🔒 HTTP-säkerhetsheaders för WordPress: komplett installationsguide

Din WordPress-sajt är igång, säkerhetspluginet är installerat, men en kontroll på securityheaders.com ger dig ett F. Låter det bekant?

HTTP-säkerhetsheaders är ett osynligt skyddslager som förbises även efter att man har satt upp en brandvägg och tvåfaktorsautentisering. De kräver inga licensförnyelser, belastar inte servern och blockerar hela attackklasser: från clickjacking till sessionskapning. Och de tar 10 minuter att lägga till.

Här nedan, steg för steg: vilka headers du faktiskt behöver, hur du konfigurerar dem via.htaccess, functions.php eller ett plugin, och hur du verifierar att skyddet fungerar, inte bara finns listat.

💡 Snabb översikt:

• Kontrollera din sajts nuvarande headers via securityheaders.com eller Mozilla Observatory för att se den verkliga bilden
• Aktivera en grunduppsättning med 4-5 headers: X-Content-Type-Options, X-Frame-Options, HSTS, Referrer-Policy, Permissions-Policy
• Välj din metod: ett par rader i.htaccess (Apache/LiteSpeed), ett snippet i functions.php eller pluginet Headers Security Advanced & HSTS WP
• Lämna CSP till senare: det är knepigt att konfigurera och kan få Gutenberg att sluta fungera om det görs utan testning
• Efter implementation, kontrollera igen: ett A+-betyg är uppnåeligt på 10 minuter

Vad HTTP-säkerhetsheaders är

När en webbläsare begär en sida skickar webbservern tillbaka mer än bara HTML-kod. Varje HTTP-svar innehåller servicefält, headers. Vissa hanterar cachelagring och innehållstyp, och vissa hanterar säkerhet.

Webbläsaren läser säkerhetsheaders innan den ens börjar rendera sidan. Om servern säger "jag förbjuder inbäddning av denna sajt i ramar" kommer webbläsaren inte att göra det, även om sidkoden innehåller en <iframe>. Om servern säger "använd endast HTTPS i ett år" kommer webbläsaren ihåg det och går inte till HTTP-versionen, även om användaren skriver in den manuellt.

Ingen JavaScript, inget plugin, ingen brandvägg påverkar detta. Detta är på protokollnivå. Det är just därför headers är en separat, oberoende försvarslinje.

Varför en WordPress-sajt behöver detta

Säkerhetsplugins som Wordfence eller Solid Security täpper till sårbarheter på applikationsnivå: brute force, injektioner, skadliga uppladdningar. HTTP-headers fungerar en nivå högre: de skyddar själva kommunikationskanalen mellan servern och besökaren.

Här är vad korrekt konfigurerade headers blockerar:

• Clickjacking. En angripare bäddar in din sajt i en genomskinlig ram ovanpå sin egen och fångar upp användarklick. Blockeras av headern X-Frame-Options eller direktivet frame-ancestors i CSP.

• MIME-sniffning. Webbläsaren försöker "gissa" filtypen och kan köra en uppladdad bild som JavaScript. Blockeras av X-Content-Type-Options: nosniff.

• Sessionskapning. En angripare på ett öppet Wi-Fi-nätverk ändrar serversvaret och stjäl inloggningskakor. HSTS förbjuder webbläsaren från att nå HTTP-versionen av sajten.

• Referrer-läckage. När man följer en extern länk ser målsajten vilken sida användaren kom från, inklusive URL:en med parametrar. Referrer-Policy begränsar detta.

• Obehörig enhetsåtkomst. En webbsida begär åtkomst till mikrofon, kamera eller geolokalisering utan användarens vetskap. Permissions-Policy blockerar sådana förfrågningar på webbläsarnivå.

CSP lägger till ytterligare ett lager: du definierar uttryckligen vilka domäner som får ladda skript, stilmallar och typsnitt. Även om skadlig kod tar sig in i databasen kommer webbläsaren inte att köra den eftersom källan inte finns i tillåtelselistan. Men CSP kräver försiktighet: ett litet misstag, och Gutenberg-redigeraren slutar fungera.

Viktiga HTTP-säkerhetsrubriker: vad de innehåller och varför

Här är rubrikerna som är värda att konfigurera på en WordPress-sajt. För varje rubrik anger vi: vilken attack den skyddar mot, rekommenderat värde och var saker kan gå sönder.

X-Content-Type-Options

Den enklaste och säkraste att konfigurera. Det enda giltiga värdet är nosniff. Webbläsaren slutar "gissa" filens MIME-typ baserat på innehållet och litar bara på den typ servern skickade i Content-Type-rubriken.

Utan denna rubrik kan webbläsaren behandla en användaruppladdad bild som ett skript och köra det, ett klassiskt scenario för filuppladdningsattacker.

Rekommenderat värde: nosniff

Risk för fel: minimal. Problem är bara möjliga om servern levererar filer med felaktig Content-Type, men det är ett separat problem som är värt att åtgärda snarare än att maskera.

X-Frame-Options

Styr om din sajt kan bäddas in i en <frame>, <iframe> eller <object> på en annan sajt.

Två huvudvärden:

• DENY, ett totalförbud mot inbäddning. Maximalt skydd.
• SAMEORIGIN, inbäddning tillåts endast från samma domän. Behövs om du själv använder ramar för dina egna sidor (till exempel förhandsvisning i adminpanelen).

För de flesta WordPress-sajter fungerar SAMEORIGIN. Om du med säkerhet vet att inga ramar används, sätt DENY.

Rekommenderat värde: SAMEORIGIN

Risk för fel: vissa tillägg använder iframes för förhandsvisningar. Om något slutar visas i adminpanelen efter att du aktiverat DENY, byt till SAMEORIGIN.

Strict-Transport-Security (HSTS)

Talar om för webbläsaren: "åtkomst till denna domän ska under de kommande N sekunderna endast ske via HTTPS." Skyddar mot nedgraderingsattacker och kapning av kakor på öppna nätverk.

Nyckelparametern är max-age. Det rekommenderas att börja med ett litet värde (en dag eller en vecka) och, efter verifiering, öka det till ett år.

Den valfria parametern includeSubDomains utökar regeln till alla underdomäner, viktigt om du har flera och använder ett CDN.

Parametern preload lägger till sajten i webbläsarnas globala HSTS-lista: Chrome, Firefox och Safari kommer endast att nå din domän via HTTPS redan före den första förfrågan. Skicka in en ansökan via hstspreload.org.

Rekommenderat värde: max-age=31536000; includeSubDomains

Risk för fel: om du aktiverar HSTS och SSL-certifikatet går ut kan användare inte nå sajten alls. Håll koll på automatisk förnyelse av certifikat.

Referrer-Policy

Hanterar vilken information om källsidan som webbläsaren skickar när användaren följer en länk till en annan sajt.

Huvudvärden, från striktaste till mest tillåtande:

• no-referrer, ingenting skickas alls.
• strict-origin-when-cross-origin, till en annan domän skickas endast domänen (ingen sökväg eller parametrar); till din egen skickas hela webbadressen. Den optimala balansen mellan integritet och analys.
• strict-origin, alltid endast domänen, ingen sökväg.

Om du inte vill att målsajter ska veta var användaren kom ifrån alls, sätt no-referrer. Men tänk på: du förlorar hänvisningstrafik i din egen analys.

Rekommenderat värde: strict-origin-when-cross-origin

Risk för fel: minimal. Vissa tredjepartstjänster kan kräva en referrer för att fungera (till exempel betalningsgateways med källverifiering). Du kan spåra sådana fall via webbläsarkonsolen.

Permissions-Policy

Hetter tidigare Feature-Policy. Begränsar webbsidans åtkomst till "hårdvarunära" webbläsar-API:er: mikrofon, kamera, geolokalisering, USB, betalnings-API:er och så vidare.

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

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

Detta exempel blockerar helt åtkomst till kamera och mikrofon för alla källor, och tillåter geolokalisering endast för sajten själv (self).

Fullständig lista över funktioner på MDN. För en WordPress-sajt utan videochattar och PWA-funktioner räcker det att blockera kamera, mikrofon och geolokalisering; resten är valfritt.

Rekommenderat värde: beror på sajtens funktionalitet. Minimum: camera=(), microphone=(), geolocation=(self).

Risk för fel: om sajten har videosamtal, PWA eller WebUSB-funktionalitet, kontrollera vilka funktioner den behöver och blockera inte dem.

Content-Security-Policy (CSP)

Den mest kraftfulla och den farligaste rubriken att konfigurera. Definierar en tillåtelselista över källor för skript, stilmallar, typsnitt, bilder, ramar och andra resurser.

Exempel på en minimal policy för 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

*Varför unsafe-inline och unsafe-eval:* WordPress, Gutenberg och dussintals tillägg genererar inline-skript och använder eval(). Utan dessa direktiv fungerar adminpanelen helt enkelt inte. Detta är priset för kompatibilitet.

Rekommendation: aktivera inte CSP först. Konfigurera de andra 5 rubrikerna först. Implementera endast CSP om du har resurser för testning och övervakning; börja med Content-Security-Policy-Report-Only-läge och samla in felloggar under ett par veckor innan du byter till tvingande läge.

Risk för fel: hög. Ett misstag i CSP kan helt förstöra frontend och adminpanel. Testa alltid i en staging-miljö eller via Report-Only.

Så kontrollerar du din sajts nuvarande rubriker

Innan konfiguration, en granskning. Tre verktyg, från enkla till detaljerade:

• securityheaders.com, ange webbadressen och få ett betyg från A+ till F med en uppdelning för varje rubrik. Gratis, ingen registrering.

• Mozilla Observatory, en mer detaljerad granskning: utvärderar inte bara rubriker utan även TLS-inställningar, kakattribut, CORS och andra aspekter. Också gratis.

• Chrome DevTools, öppna fliken Nätverk, välj valfri förfrågan till din sajt och titta på sektionen Response Headers. Ett snabbt sätt att kontrollera om ändringar "tog" efter redigering av.htaccess.

Kontrollera din sajt nu. Om betyget är under B har du inte ens grundläggande rubriker, och en tredjedel av punkterna nedan konfigurerar du på 5 minuter.

Sätt att konfigurera HTTP-headers i WordPress

Tre vägar, från manuell till automatisk. Välj utifrån din situation.

Metod 1: Via.htaccess (Apache/LiteSpeed)

Den snabbaste metoden för sajter på Apache eller LiteSpeed. Lägg till i .htaccess-filen i sajtroten (före # 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>

Omslaget <IfModule mod_headers.c> säkerställer att sajten inte kraschar med ett 500-fel om modulen mod_headers inte är aktiverad. Om du vet säkert att den är aktiv kan du utelämna det.

Efter att du sparat, kör i terminalen (om du har WP-CLI) eller öppna helt enkelt sajten och kontrollera headers via securityheaders.com. Ändringar i .htaccess slår igenom direkt; ingen omstart av servern behövs.

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

Fungerar oavsett webbserver, lämplig för både Nginx och Apache. Lägg till i functions.php i ditt child theme eller via tillägget Code Snippets:

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' );

Hooken send_headers körs innan WordPress börjar skicka innehåll, så headers skickas ut i det allra första serversvaret.

För Nginx är denna metod att föredra framför att gräva i serverkonfigurationen (särskilt på delade hostingar, där åtkomst till nginx.conf ofta saknas). Nackdelen: headers fungerar bara för PHP-förfrågningar som passerar genom WordPress. Statiska filer (bilder, CSS, JS) serveras direkt av Nginx och får inte headers. De kräver konfiguration på servernivå.

Metod 3: Via tillägget headers security advanced & hsts wp

Om du inte vill röra kod, använd ett dedikerat tillägg. Headers Security Advanced & HSTS WP samlar alla säkerhetsheaders i ett gränssnitt och aktiverar dem med en enda knapp.

Tillägget sätter förinställda värden för alla viktiga headers direkt efter aktivering: X-Content-Type-Options, X-Frame-Options, HSTS, CSP, Referrer-Policy, Permissions-Policy och flera ytterligare (CORP, COOP, COEP). Varje header kan inaktiveras eller anpassas efter dina behov.

Fördelen med detta tillvägagångssätt: tillägget är inte beroende av webbservern och fungerar identiskt på Apache, Nginx, LiteSpeed och IIS. Vid avaktivering återställer det sajtens konfiguration till sitt ursprungliga skick.

Alternativ: Redirection

Tillägget Redirection är känt som en omdirigeringshanterare, men det kan också lägga till HTTP-headers. Efter installation och grundläggande inställning, gå till avsnittet Site → Headers; gränssnittet låter dig ange valfria "header: värde"-par.

Detta alternativ fungerar om du redan har Redirection installerat för länkhantering och inte vill lägga till ytterligare ett tillägg. Men ett dedikerat header-tillägg ger mer kontroll och förinställda värden.

I videon visas en visuell demonstration av att konfigurera headers via tillägget Headers Security Advanced: från installation till verifiering av resultatet på securityheaders.com.

⁉️🤔 Vanliga frågor

Vad händer om sajten går sönder efter att headers aktiverats?

Kontrollera först Content-Security-Policy-headern: den orsakar de allra flesta problem. Inaktivera CSP (eller växla den till Report-Only-läge) och kontrollera sajten igen. Ett 500-fel efter redigering av.htaccess: kontrollera syntaxen efter ett extra mellanslag, oslutna citattecken eller en saknad mod_headers-modul. Via FTP, byt namn på.htaccess, så kommer sajten tillbaka till liv, och du kan i lugn och ro hitta felet.

I 9 av 10 fall är problemet specifikt CSP, inte de andra headers. X-Content-Type-Options, X-Frame-Options, HSTS och Referrer-Policy kan fysiskt inte förstöra sajten; de påverkar inte rendering eller PHP-logik. Börja alltid med dessa.

Är ett tillägg obligatoriskt, eller kan det göras via kod?

Det kan och bör göras via kod om du vet hur man redigerar functions.php eller.htaccess. Att sätta headers direkt via serverkonfiguration fungerar snabbare än ett tillägg, utan något PHP-lager emellan. Men ett tillägg är bekvämare för dem som inte vill röra kod och ger ett visuellt gränssnitt med förinställningar för varje header.

På våra testsajter använder vi båda tillvägagångssätten: i produktion,.htaccess (färre felkällor); på kundsajter där hostingen inte tillåter redigering av konfigurationen, tillägget. Resultatet på securityheaders.com är identiskt: A+ i båda fallen.

Behöver jag konfigurera CSP om sajten ligger på WordPress?

För de flesta sajter, nej. CSP på WordPress kräver unsafe-inline och unsafe-eval för att Gutenberg och dussintals tillägg ska fungera, vilket reducerar den skyddande effekten till symbolisk. En fullfjädrad CSP är meningsfull på högtrafikerade projekt med en dedikerad säkerhetsspecialist som analyserar varje överträdelserapport. För alla andra ger de 5 grundläggande headers lejonparten av det praktiska skyddet.

Hur verifierar jag att headers fungerar efter installation?

Öppna sajten i en webbläsare, starta DevTools (F12) → fliken Network → klicka på den första förfrågan till din domän → avsnittet Response Headers. Om du ser de tillagda headers fungerar allt. För automatiserad verifiering, använd securityheaders.com: det visar inte bara närvaro utan också korrekthet i värden, plus ett slutbetyg från A+ till F.

Vad händer om hostingen inte tillåter redigering av.htaccess och det inte finns åtkomst till functions.php?

Installera Headers Security Advanced & HSTS WP via WordPress adminpanel. Tillägget injicerar headers på PHP-nivå och kräver inte redigering av serverfiler. Detta fungerar på alla hostingar där WordPress körs, från billiga delade till Managed WordPress.

Påverkar HTTP-headers sajtens hastighet?

Praktiskt taget inte. Headers är ett par dussin byte text i serversvaret. De utför inga beräkningar, gör inga databasfrågor och belastar inte processorn. Fördröjningen de lägger till mäts i mikrosekunder. Det enda undantaget är CSP med en komplex tillåtelselista på hundratals domäner: webbläsaren lägger tid på att tolka den, men även då överstiger påverkan på renderingshastigheten inte ett par millisekunder.

Vad man ska ställa in och var man ska börja

HTTP-säkerhetsheaders är inte en engångsåtgärd av typen "ställ in och glöm". De är en grundnivå som bör finnas på varje sajt som standard, som ett SSL-certifikat.

Planen för idag:

• Kontrollera din sajt på securityheaders.com. Om betyget är D eller F har du inte ens X-Content-Type-Options.

• Lägg till de 5 grundläggande headers med någon av de tre metoderna ovan. Om sajten ligger på Apache, via.htaccess (30 sekunder). Nginx utan konfigurationsåtkomst, via functions.php (2 minuter). Om du inte vill röra kod, tillägget Headers Security Advanced (3 minuter inklusive installation).

• Kontrollera igen sajten. Betyget bör stiga till A eller A+.

• Lägg CSP åt sidan. Återkom till det när de grundläggande headers har fungerat i en månad utan problem och du har tid för testning via Report-Only.

En timme, och din WordPress-sajt får ett lager av försvar som den stora majoriteten av sajter på internet saknar. Börja med en kontroll redan nu.