Headers de sécurité : HSTS, CSP, X-Frame-Options et autres

En bref : Les headers HTTP de sécurité sont des lignes que le serveur ajoute à chaque réponse HTTP pour dire au navigateur comment traiter votre site. Correctement réglés, ils éliminent des classes entières d'attaques (XSS, clickjacking, MITM) - et ils sont gratuits.

Pourquoi c'est important

Une application peut être parfaitement sécurisée côté backend, mais sans headers corrects, toujours vulnérable aux attaques côté navigateur : cross-site scripting (XSS), clickjacking, protocol downgrade, MIME confusion. Les headers de sécurité poussent la défense dans le navigateur.

Strict-Transport-Security (HSTS)

Force HTTPS pour toutes les visites futures. Après la première visite HTTPS, le navigateur mémorise le domaine et réécrit lui-même tout lien http:// en https://, même si l'utilisateur clique sur une mauvaise réponse.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• max-age=63072000 = valide 2 ans
• includeSubDomains = la règle s'applique aussi à tous les sous-domaines (attention : si vous avez un sous-domaine HTTP-only, ça le casse)
• preload = permet l'inclusion dans la liste HSTS preload intégrée à Chrome / Firefox / Safari

Attention : HSTS avec preload prend 6+ mois pour retirer de la liste. N'incluez pas preload avant d'avoir vérifié que HTTPS fonctionne de manière stable pour tous les sous-domaines.

Content-Security-Policy (CSP)

Le header le plus puissant mais aussi le plus difficile à configurer. Whitelist d'où le navigateur peut charger scripts, styles, images, iframes. Sans CSP, un attaquant qui peut injecter une balise <script> peut exécuter n'importe quel JS - avec CSP seulement du code provenant de sources approuvées.

Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-...'; img-src 'self' data: https://cdn.example.com; style-src 'self' 'unsafe-inline'; frame-ancestors 'none'

Directives courantes :

• default-src 'self' = par défaut autorise seulement les ressources de mon domaine
• script-src = sources JS (spécifiez hash ou nonce pour scripts inline)
• style-src = sources CSS
• img-src = images
• connect-src = AJAX, WebSocket, EventSource
• frame-ancestors 'none' = personne ne peut embed la page dans iframe (mieux que X-Frame-Options)
• report-uri /csp-report = le navigateur envoie JSON à chaque violation (vous attrapez dans le backend et loggez)

X-Frame-Options

Alternative plus ancienne à frame-ancestors. Empêche le clickjacking - l'attaquant insère votre page comme iframe et la recouvre de boutons invisibles.

X-Frame-Options: DENY

Valeurs : DENY (personne), SAMEORIGIN (uniquement mon domaine), ALLOW-FROM uri (deprecated).

X-Content-Type-Options

X-Content-Type-Options: nosniff

Désactive le MIME sniffing - le navigateur respectera le Content-Type que le serveur a renvoyé. Sans ça, un attaquant peut uploader un fichier avec le mauvais type (par ex. une image qui est en réalité du HTML avec script) et le navigateur peut l'exécuter comme page web.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Contrôle combien d'informations sur la page précédente le navigateur envoie dans le header Referer au clic. Le défaut dans les navigateurs modernes est déjà strict-origin-when-cross-origin, mais le header déclaratif explicite assure la cohérence.

Permissions-Policy

Désactive les API dont vous n'avez pas besoin - caméra, microphone, GPS, géolocalisation. Un attaquant via XSS ne peut pas demander ces API.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Configuration pratique en nginx

server {
  listen 443 ssl http2;
  server_name example.com;

  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header X-Frame-Options "DENY" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

  # CSP est étendu - définissez selon votre application
  add_header Content-Security-Policy "default-src 'self'; script-src 'self'; ..." always;
}

La clé est always - sans ça nginx omet les headers sur les réponses d'erreur (4xx, 5xx).

Audit de l'état actuel

Le plus facile via un outil en ligne. Notre header check vous montrera quels headers manquent et lesquels sont incorrects. Pour un audit approfondi, securityheaders.com donne aussi une note A-F.

Conclusion

Les headers de sécurité sont l'un des meilleurs investissements en rapport effort/gain dans le domaine de la sécurité - typiquement une demi-heure de setup en reverse proxy contre toute une catégorie d'attaques côté navigateur. Un audit une fois par semestre dans le cadre de la maintenance régulière est un minimum raisonnable.

Audit gratuit des security headers

Sans inscription, résultat en trois secondes.

Tester le site →