Hvad er HTTP-sikkerhedsheadere?

Question

Accepted Answer

**HTTP-sikkerhedsheadere** er response-headere, der instruerer browsere til at håndhæve sikkerhedsbeskyttelser — og hjælper med at forsvare mod angreb som XSS, clickjacking og protokolnedgradering. De er et let og værdifuldt forsvarslag for webapplikationer.

## Vigtige sikkerhedsheadere

```text
CONTENT-SECURITY-POLICY (CSP) → controls what resources/scripts can load/run → a strong
  defense against XSS (restrict script sources; block inline scripts) — the most powerful
STRICT-TRANSPORT-SECURITY (HSTS) → force HTTPS (browser refuses HTTP) → prevents
  downgrade/SSL-stripping attacks
X-CONTENT-TYPE-OPTIONS: nosniff → stop MIME-type sniffing (prevents some attacks)
X-FRAME-OPTIONS / CSP frame-ancestors → prevent CLICKJACKING (block embedding in iframes)
REFERRER-POLICY → control how much referrer info is sent (privacy)
PERMISSIONS-POLICY → control access to browser features (camera, geolocation, etc.)
```

## Eksempel

```text
Content-Security-Policy: default-src 'self'; script-src 'self'
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
```

## Hvorfor de betyder noget (forsvar i dybden)

```text
✓ EASY to add (configure on the server/proxy) → significant protection for little effort
✓ DEFENSE IN DEPTH → an extra layer (e.g. CSP mitigates XSS even if escaping is missed)
✓ CLICKJACKING protection (X-Frame-Options), forced HTTPS (HSTS), etc.
⚠️ Not a substitute for secure coding (fix the root causes too); CSP needs careful config
→ A valuable, low-effort security improvement for web apps. (Tools/scanners check these.)
```

## Hvorfor det betyder noget

At forstå HTTP-sikkerhedsheadere er værdifuldt, fordi de giver **et let og effektivt forsvarslag for webapplikationer**, og det er derfor brugbar praktisk sikkerhedsviden.

Sikkerhedsheadere instruerer browsere til at håndhæve beskyttelser mod almindelige angreb, og det er værdifuldt at forstå de vigtige. **Content-Security-Policy (CSP)** er den mest kraftfulde — den styrer, hvilke ressourcer og scripts der kan indlæses og køres, og giver et stærkt forsvar mod XSS (og kan endda afbøde det, når output-escaping er blevet overset). **Strict-Transport-Security (HSTS)** tvinger HTTPS, hvilket forhindrer nedgraderings- og SSL-stripping-angreb. **X-Frame-Options** (eller CSP frame-ancestors) forhindrer **clickjacking** ved at blokere siden fra at blive indlejret i iframes. **X-Content-Type-Options: nosniff**, Referrer-Policy og Permissions-Policy tilføjer yderligere beskyttelser.

At forstå disse headere og hvad de beskytter mod, er den praktiske viden.

At forstå **hvorfor de betyder noget** er den vigtige værdi: de er **nemme at tilføje** (konfigureret på serveren/proxyen) og giver alligevel betydelig beskyttelse for lille indsats, og de implementerer **forsvar i dybden** (ekstra lag — f.eks. CSP, der afbøder XSS selv hvis en kodningsmistag tillader det).

At forstå den vigtige advarsel, at **headere ikke er en erstatning for sikker kodning** (du skal stadig løse grundlæggende årsager; CSP kræver omhyggelig konfiguration) afspejler en afbalanceret forståelse — headere supplerer, men erstatter ikke, sikker udvikling.

Sikkerhedsheadere er en værdifuld, lavindsats-forbedring, som mange websteder underkommunikerer, og værktøjer/scannere kontrollerer hyppigt for dem.

Fordi sikkerhedsheadere giver let, effektivt forsvar-i-dybden for webapplikationer (der beskytter mod XSS, clickjacking, nedgraderings-angreb) for lille indsats, og fordi det er brugbart at forstå de vigtige headere og deres værdi for at forbedre webapplikationssikkerheden, er det værdifuld, praktisk-relevant sikkerhedsviden at forstå HTTP-sikkerhedsheadere — et lavindsats, høj-værdi-forsvarslag til web (især CSP for XSS og X-Frame-Options for clickjacking), der supplerer sikker kodning, brugbar viden til at hærdere webapplikationer.