HTTP Security Headers : HSTS, CSP, X-Frame-Options expliqués

Sept en-têtes HTTP de sécurité bloquent l'essentiel des attaques web côté navigateur : injection de script, clickjacking, fuite de données, man-in-the-middle. Configuration sur Nginx, Apache et Cloudflare.

Par Constantin Boulanger
Publié le
9 min de lecture

Les HTTP Security Headers sont des en-têtes envoyés par votre serveur web qui demandent au navigateur d'appliquer des règles de sécurité spécifiques : forcer HTTPS (HSTS), bloquer les scripts non autorisés (CSP), empêcher l'embarquement dans une iframe (X-Frame-Options), limiter la fuite d'information (Referrer-Policy), etc. Ils constituent la première ligne de défense côté navigateur — gratuite, configurée en quelques lignes, et active immédiatement.

Pourtant, la majorité des sites web français en 2026 n'envoient aucun de ces en-têtes ou des configurations dépassées. Voici les sept headers à connaître, à quoi ils servent et comment les configurer sur les principaux serveurs web.

Les 7 headers à configurer en priorité

1. Strict-Transport-Security (HSTS)

Force le navigateur à n'utiliser que HTTPS sur votre domaine, même si l'utilisateur tape http://. Bloque les attaques de downgrade SSL et empêche le bypass d'un certificat invalide.

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

max-age=31536000 = 1 an. includeSubDomains applique HSTS à tous les sous-domaines. preload permet l'inscription sur la liste HSTS Preload des navigateurs (très fort, mais difficile à révoquer).

2. Content-Security-Policy (CSP)

Définit quelles sources de contenu (scripts, images, fonts, etc.) le navigateur a le droit de charger sur votre page. Bloque les attaques XSS en empêchant l'exécution de scripts injectés.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.exemple.com; img-src 'self' data:; style-src 'self' 'unsafe-inline'

CSP est puissant mais demande un travail de tuning : une politique trop stricte casse votre site, une politique trop permissive ne protège rien. Commencer en mode Report-Only pour identifier les ressources légitimes avant d'enforcer.

3. X-Frame-Options

Empêche votre site d'être embarqué dans une iframe sur un autre domaine. Bloque le clickjacking (attaque qui superpose un iframe transparent au-dessus d'un faux bouton pour faire cliquer l'utilisateur sans le savoir).

X-Frame-Options: DENY

Trois valeurs possibles : DENY (interdit toute iframe), SAMEORIGIN (autorise iframe depuis le même domaine), ALLOW-FROM uri (déprécié, utiliser CSP frame-ancestors).

4. X-Content-Type-Options

Empêche le navigateur de deviner (MIME-sniffer) le type de contenu d'une ressource. Bloque les attaques où un fichier uploadé est interprété comme du HTML/JS.

X-Content-Type-Options: nosniff

Une seule valeur valide (nosniff), à mettre systématiquement.

5. Referrer-Policy

Contrôle quelle information sur l'URL d'origine est envoyée quand l'utilisateur clique sur un lien sortant. Limite la fuite de données privées via l'en-tête Referer.

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

Bonne valeur par défaut : envoie le domaine complet sur navigation interne, juste l'origine sur navigation cross-domain HTTPS, rien si downgrade vers HTTP.

6. Permissions-Policy

Désactive l'accès du site à des APIs sensibles du navigateur (caméra, microphone, géolocalisation, etc.). Limite l'impact d'un script tiers compromis.

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

Les parenthèses vides désactivent l'API. Exemple plus permissif : geolocation=(self) autorise uniquement votre origine.

7. Cross-Origin-Opener-Policy (COOP) + Cross-Origin-Embedder-Policy (COEP)

Couche de sécurité avancée pour les sites qui manipulent des données sensibles (banking, dashboard). Active cross-origin isolation, requis pour SharedArrayBuffer et la défense contre Spectre.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Configuration sur Nginx

Ajouter dans le bloc server ou location :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'" always;

Le flag always applique l'en-tête même sur les réponses d'erreur (404, 500). Sans always, certaines réponses ne portent pas les en-têtes — failure mode classique.

Configuration sur Apache

Activer mod_headers (a2enmod headers) puis ajouter dans le VirtualHost ou .htaccess :

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "DENY"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Content-Security-Policy "default-src 'self'"

Configuration sur Cloudflare

Méthode 1 — Transform Rules (UI) :

  1. Dashboard Cloudflare → votre domaine → RulesTransform RulesModify Response Header
  2. Cliquer Create rule
  3. Condition : (http.host eq "votre-domaine.fr")
  4. Action : Set static pour chaque header

Méthode 2 — Workers : pour configurations dynamiques par route, utiliser un Cloudflare Worker qui ajoute les en-têtes via response.headers.set().

Comment auditer vos headers actuels

Trois outils gratuits :

  • securityheaders.com : note A à F + détail des en-têtes manquants ou mal configurés.
  • Mozilla Observatory (observatory.mozilla.org) : audit complet avec recommandations.
  • Notre HTTP Headers Checker gratuit : vérification rapide en un clic.

Pièges fréquents

  • HSTS preload sans réflexion : la suppression de la preload list prend 6-12 mois. Ne preload qu'après plusieurs mois de HSTS stable sur tous les sous-domaines.
  • CSP en mode strict d'emblée : casse souvent le site. Phase Report-Only de 2-4 semaines pour identifier les ressources légitimes.
  • X-XSS-Protection : déprécié et même contre-productif sur certains navigateurs. À retirer si présent.
  • Headers en double : si configurés à plusieurs endroits (Nginx + Cloudflare), le navigateur peut recevoir des valeurs contradictoires. Définir à un seul niveau.

Ce qu'il faut retenir

  • Sept en-têtes couvrent l'essentiel des défenses navigateur : HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP/COEP.
  • Configuration en quelques lignes sur Nginx, Apache, Cloudflare.
  • CSP demande du tuning — déployer en Report-Only avant d'enforcer.
  • HSTS preload est puissant mais difficile à révoquer.
  • Audit gratuit via securityheaders.com, Mozilla Observatory, ou notre outil HTTP Headers.

Questions fréquentes

Quels headers sont les plus critiques en 2026 ?

Quatre incontournables : HSTS (force HTTPS), CSP (bloque XSS), X-Frame-Options (clickjacking), X-Content-Type-Options nosniff. Les trois autres (Referrer-Policy, Permissions-Policy, COOP/COEP) sont importants mais moins urgents.

HSTS preload est-il définitif ?

Pratiquement oui. La suppression de la liste preload dans Chrome/Firefox prend 6-12 mois et n'est pas garantie. À n'activer qu'après plusieurs mois de HSTS sans incident sur tous les sous-domaines.

CSP avec 'unsafe-inline' a-t-il un intérêt ?

Limité. 'unsafe-inline' autorise l'exécution de scripts inline, ce qui annule la protection XSS. C'est parfois nécessaire pour la rétro-compatibilité, mais la cible est 'nonce-XYZ' ou 'sha256-...' qui maintient le bénéfice CSP.

Comment savoir si CSP casse mon site ?

Mode Report-Only : Content-Security-Policy-Report-Only au lieu de Content-Security-Policy. Le navigateur signale les violations sans bloquer. Configurer report-uri pour collecter les rapports avant de switcher en mode bloquant.

Les security headers impactent-ils les performances ?

Quelques octets par requête. Imperceptible. Le coût en performance est nul, le bénéfice en sécurité massif.

Faut-il configurer ces headers sur les sous-domaines aussi ?

Oui, chaque sous-domaine doit avoir sa propre configuration. includeSubDomains de HSTS étend la protection mais les autres en-têtes sont par-réponse — donc à appliquer partout.

Auditer + monitorer en continu

Les security headers sont gratuits, simples à configurer, et bloquent l'essentiel des attaques côté navigateur. La seule difficulté : maintenir la configuration cohérente sur tous les domaines et sous-domaines au fil du temps.

Domains Defender vérifie continuellement la présence des en-têtes critiques sur vos domaines surveillés et alerte si une configuration disparaît (suite à un déploiement, un changement de proxy, etc.). Hébergé en France, conforme RGPD, essai gratuit 7 jours à partir de 4,99€ HT/mois.

Auditer vos headers gratuitement — ou activer la surveillance continue.