# Säkerhetsheaders för webbplatser: sätt säkerhetsheaders rätt

> Sätt säkerhetsheaders för webbplatser: CSP, HSTS, X-Content-Type-Options och mer med exempel för Nginx och Apache, samt kontroll och typiska fel.

Källa: https://phpsos.de/sv/ratgeber/sicherheits-header/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** Säkerhetsheaders är webbserverns anvisningar till webbläsaren som skyddar besökare mot angrepp som cross-site scripting, clickjacking och okrypterade förbindelser. De viktigaste är HSTS, Content-Security-Policy, X-Content-Type-Options, skydd mot främmande ramar, Referrer-Policy och Permissions-Policy. De är en meningsfull härdning men ersätter inga uppdateringar på servern.

## Vad säkerhetsheaders åstadkommer och vad de inte gör

Vid varje sidanrop skickar webbservern förutom innehållet också headers. Några av dem styr webbläsarens säkerhetsfunktioner. Därmed kan man till exempel fastställa att en sida bara laddas via HTTPS eller att webbläsaren inte kör skript från främmande domäner.

För driftansvariga är bedömningen viktig: Headers skyddar i första hand besökarna, till exempel mot att sessioner snappas upp eller mot manipulerade formulär. De stänger inga sårbarheter på servern. En svaghet i PHP, i CMS:et eller i ett tillägg finns kvar hur väl headers än är satta. I samspel med ren kod begränsar de dock följderna av många fel avsevärt.

## De viktigaste säkerhetsheaders i överblick

| Header | Syfte | Rekommendation som utgångspunkt |
|---|---|---|
| Strict-Transport-Security (HSTS) | tvingar HTTPS vid framtida anrop | `max-age=31536000; includeSubDomains` |
| Content-Security-Policy (CSP) | fastställer tillåtna källor för skript, bilder, ramar | individuellt, först som report-only |
| X-Content-Type-Options | hindrar webbläsaren från att gissa filtyper | `nosniff` |
| X-Frame-Options respektive CSP frame-ancestors | hindrar inbäddning i främmande sidor (clickjacking) | `SAMEORIGIN` respektive `frame-ancestors 'self'` |
| Referrer-Policy | begränsar vilken adress som lämnas till andra sidor | `strict-origin-when-cross-origin` |
| Permissions-Policy | stänger av webbläsarfunktioner som kamera eller plats | tillåt bara funktioner som behövs |

HSTS bör ni sätta först när alla underdomäner är tillförlitligt nåbara via HTTPS. Webbläsaren minns anvisningen under den angivna tiden; ett fel går då inte att ta tillbaka direkt. Börja vid behov med en kort löptid och öka den efter lyckade tester. Tillvalet `preload` för permanent in domänen i webbläsartillverkarnas listor och bör sättas först efter noggrann granskning.

Headers är dessutom inte den enda platsen där webbläsaren erbjuder skydd. Cookies bör ha attributen `Secure`, `HttpOnly` och `SameSite`, så att sessioner inte snappas upp via okrypterade förbindelser eller skript. Hur ni ställer in det i PHP beskriver guiden om sessioner.

## Sätta säkerhetsheaders i Nginx

I Nginx hör headers hemma i `server`-blocket för respektive webbplats. Tillägget `always` ser till att de skickas även på felsidor.

```nginx
server {
    # ...
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; form-action 'self'" always;

    server_tokens off;
}
```

En egenhet hos Nginx: Sätter ett `location`-block egna `add_header`-direktiv tas headers från `server`-blocket inte över där. Kontrollera därför även undersidor och statiska filer. Ytterligare härdning för den här kombinationen beskriver [Skydda Nginx med PHP-FPM](https://phpsos.de/sv/server/nginx-php-fpm/).

## Sätta säkerhetsheaders i Apache

Under Apache behöver ni modulen `mod_headers`. Direktiven hör hemma i VirtualHost eller, om åtkomst saknas dit, i `.htaccess`.

```apache
<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 X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
</IfModule>

ServerTokens Prod
ServerSignature Off
```

`ServerTokens` och `ServerSignature` hör hemma i huvudkonfigurationen. De hindrar servern från att uppge sin exakta version i svar och felsidor. I `php.ini` uppnår ni samma sak för PHP med `expose_php = Off`.

## Inför Content-Security-Policy stegvis

Content-Security-Policy är den mest verksamma men också mest krävande headern. Den fastställer från vilka källor skript, stilmallar, bilder, typsnitt och ramar får laddas. Laddas ett insmugglat skript från en främmande domän blockerar webbläsaren det.

Moderna webbplatser bäddar ofta in analysverktyg, betalleverantörer, karttjänster eller videor. En för sträng policy lamslår då funktioner. Gå därför fram i steg:

- Börja först med `Content-Security-Policy-Report-Only`. Webbläsaren rapporterar överträdelser i utvecklarkonsolen eller till en samlingsadress men blockerar ingenting.
- Kartlägg alla källor som behövs och frisläpp dem riktat, i stället för att använda generella jokertecken.
- Lägg ut inline-skript stegvis i filer eller förse dem med nonces, så att man kan avstå från `'unsafe-inline'`.
- Växla först efter en testfas utan oväntade rapporter över till `Content-Security-Policy`.

> **Tips:**
> CSP kompletterar ren escaping i koden men ersätter den inte. Hur ni skyddar utmatningar i PHP rätt står i guiden [Förhindra cross-site scripting i PHP](https://phpsos.de/sv/ratgeber/xss-php/).

## Kontrollera headers och undvik typiska fel

Efter varje ändring bör ni kontrollera att headers verkligen kommer fram. Det går utan extra verktyg med `curl`:

```bash
# Testa konfigurationen och ladda om
nginx -t && systemctl reload nginx

# Visa headers för startsidan och en statisk fil
curl -sI https://www.example.de/ | grep -iE 'strict|content-security|x-content|x-frame|referrer|permissions|server'
curl -sI https://www.example.de/favicon.ico | grep -iE 'strict|x-content'
```

Typiska fel är dubbelt satta headers när webbserver och applikation skickar samma headers, ett förkopplat CDN som tar bort eller skriver över headers, och headers som bara syns på startsidan men inte vid omdirigeringar eller felsidor. Kontrollera dessutom efter uppdateringar av CMS:et eller av säkerhetstillägg om headers har ändrats.

Bestäm därför ett ställe där headers underhålls, helst webbservern eller den förkopplade tjänsten. Många CMS-tillägg erbjuder också inställningar för säkerhetsheaders. Det är bekvämt men leder lätt till dubbla eller motstridiga uppgifter om servern dessutom sätter headers. För enskilda tester passar även webbläsarens utvecklarverktyg: På nätverksfliken ser ni svarsheaders för varje förfrågan, och konsolen visar överträdelser av Content-Security-Policy.

## Hur hjälper PHP SOS konkret?

- Vi granskar de aktuella headerna för alla era webbplatser, även bakom CDN och proxy, och pekar ut luckor och motsägelser.
- Vi sätter headers centralt i webbservern inom ramen för [serverhärdningen](https://phpsos.de/sv/leistungen/server-haertung/) och testar startsida, undersidor och felsidor.
- Vi inför Content-Security-Policy i report-only-läge, utvärderar rapporterna och aktiverar den efter samråd.
- Där kodändringar inte är möjliga direkt kompletterar vi skyddet med [WAF-regler och virtuell patchning](https://phpsos.de/sv/leistungen/waf-virtuelles-patching/).


## Vanliga frågor

**Vad är säkerhetsheaders?**  
Säkerhetsheaders är tilläggsuppgifter i webbserverns svar. De talar till exempel om för webbläsaren att den bara ska ladda sidan via HTTPS, inte köra främmande skript eller inte visa sidan i främmande ramar. De skyddar framför allt besökarna.

**Skyddar säkerhetsheaders mot PHP2Shell?**  
Nej. PHP2Shell är en sårbarhet i PHP på servern, headers verkar i besökarens webbläsare. Mot PHP2Shell hjälper uppdateringen till en åtgärdad PHP-version och omstarten av alla workers. Headers är en kompletterande härdning mot andra angreppstyper.

**Kan en Content Security Policy förstöra min webbplats?**  
Ja, en för sträng policy blockerar skript, typsnitt eller inbäddat innehåll som behövs. Därför inför man den först i report-only-läge, utvärderar rapporterna och växlar först därefter till tillämpning.

**Är X-XSS-Protection fortfarande meningsfull?**  
Nej. Aktuella webbläsare utvärderar inte längre den headern, och rekommendationen är att utelämna den eller sätta den till 0. Skydd mot cross-site scripting ger ren escaping i koden och en Content Security Policy.

## Källor

- [OWASP Cheat Sheet Series (HTTP Headers)](https://cheatsheetseries.owasp.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [BSI: rekommendationer för webbservrar](https://www.bsi.bund.de/)