---
title: Slik setter dere sikkerhetsheadere som faktisk gjør noe
description: Hvilke svarhoder som er verdt å sette, i hvilken rekkefølge, og hvordan dere ruller ut en CSP uten å ta ned deres egen nettside.
updated: 2026-08-16
minutes: 25
canonical: https://glippen.no/veiledninger/sikkerhetsheadere
author: Erik Nilsen
---

# Slik setter dere sikkerhetsheadere som faktisk gjør noe

Svarhoder er instruksjoner nettleseren følger. De koster ingenting å sette, de krever ingen endring i koden, og de fjerner hele klasser av angrep som ellers må håndteres ett sted om gangen.

De er også lette å sette feil. En for streng CSP tar ned nettsiden, og en for slapp CSP gjør ingenting mens den ser ut som den gjør noe. Rekkefølgen under starter med de trygge.

> Alle kommandoene under leser. Ingen av dem endrer noe.

## 1. Se hva dere sender i dag

Hent svarhodene for forsiden og les dem.

```sh
curl -sI https://example.no | sort
```

**Riktig svar.** En liste med svarhoder. De fleste nettsteder mangler alt under, og noen sender i tillegg en Server-header som forteller nøyaktig hvilken versjon som kjører.

## 2. Sett de tre trygge først

Disse tre kan settes med en gang. De tar ikke ned noe, og de fjerner de enkleste angrepene.

Strict-Transport-Security tvinger nettleseren til HTTPS, også første gang. X-Content-Type-Options: nosniff stopper nettleseren fra å gjette filtypen, som er hvordan en opplastet bildefil blir kjørt som skript. Referrer-Policy hindrer at hele adressen, med det som måtte stå i den, sendes videre til andre nettsteder.

```sh
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
```

**Pass på.** includeSubDomains gjelder alle underdomener, også de dere har glemt. Har dere et internt verktøy på HTTP under samme domene, slutter det å virke. Sjekk listen før dere setter den, og vent med preload til dere er sikre: preload er vanskelig å reversere.

## 3. Legg til Content-Security-Policy i rapportmodus

CSP er den som virkelig betyr noe, og den som tar ned nettsider. Derfor settes den først i en variant som bare rapporterer.

Content-Security-Policy-Report-Only gjør ingenting annet enn å si fra om hva den ville blokkert. La den stå slik til rapportene er stille.

```sh
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-rapport
```

## 4. Stram inn og bytt til håndheving

Rapportene viser hva siden faktisk laster: analyseverktøy, skrifter, innebygde videoer. Legg til det som skal være der, og bare det.

Når rapportene er tomme, fjerner dere Report-Only fra navnet. Da håndheves den.

frame-ancestors i CSP erstatter den gamle X-Frame-Options. Setter dere frame-ancestors, trenger dere ikke den gamle, men den skader ikke å ha med for eldre nettlesere.

**Pass på.** unsafe-inline i script-src gjør CSP-en nesten virkningsløs mot den angrepstypen den er laget for. Trenger dere innebygde skript, bruk nonce eller hash i stedet. En CSP med unsafe-inline består en overfladisk test og stopper ingenting.

## 5. Fjern det som røper mer enn nødvendig

Server og X-Powered-By forteller hvilken programvare og hvilken versjon som kjører. Det er ikke et hull i seg selv, men det sparer den som leter for tid.

Permissions-Policy slår av nettleserfunksjoner siden ikke bruker, som kamera, mikrofon og posisjon.

## Det som faktisk går galt

- CSP med unsafe-inline. Ser ut som en CSP, stopper ikke det en CSP er til for.
- HSTS med preload satt for tidlig. Det er lett å slå på og vanskelig å angre.
- Headere satt i applikasjonen og i proxyen samtidig, med ulike verdier. Hvilken som vinner avhenger av oppsettet, og svaret er sjelden det noen hadde tenkt.
- Headere satt på forsiden, men ikke på API-et eller på feilsider.
- En CSP kopiert fra et annet nettsted. Den passer det nettstedet, ikke deres.