Comment auditer la sécurité de vos headers HTTP en 8 étapes

Les en-têtes HTTP de sécurité sont des instructions que votre serveur web envoie au navigateur de vos visiteurs pour définir comment le contenu doit être traité. Un Content-Security-Policy bien configuré peut bloquer 95% des attaques XSS. Un HSTS mal déployé peut rendre votre site inaccessible. Ces en-têtes sont invisibles pour vos utilisateurs mais critiques pour la sécurité de votre infrastructure web.

En 2026, les navigateurs deviennent de plus en plus stricts. Chrome affiche désormais des avertissements pour les sites sans HSTS sur les pages de paiement. Les scanners automatisés des assureurs cyber vérifient systématiquement vos headers avant de calculer votre prime. Et les exigences NIS2 imposent des mesures techniques de sécurité dont les headers HTTP font partie intégrante.

Ce guide vous donne une méthodologie complète en 8 étapes pour auditer, corriger et surveiller vos en-têtes HTTP de sécurité. Que vous gériez un site WordPress, une application Next.js ou une architecture microservices derrière un reverse proxy, chaque étape est adaptée à votre contexte.

Étape 1 : Inventorier vos headers actuels avec curl

Avant toute correction, vous devez connaître l’état exact de vos headers. La commande curl -I -L https://votre-domaine.com affiche tous les en-têtes de réponse, y compris les redirections. Le flag -L suit les redirections HTTP vers HTTPS, ce qui vous permet de vérifier que le HSTS est présent dès la première réponse HTTPS.

Documentez chaque en-tête dans un tableur avec trois colonnes : nom du header, valeur actuelle, valeur cible. Cette cartographie sera votre référence tout au long de l’audit. Testez également vos sous-domaines — api.votre-domaine.com, cdn.votre-domaine.com — car chaque point d’entrée peut avoir une configuration différente.

Étape 2 : Scanner avec securityheaders.com et Mozilla Observatory

Deux outils gratuits fournissent une évaluation instantanée. Le site securityheaders.com attribue une note de A+ à F en analysant la présence et la configuration de chaque header de sécurité. Mozilla Observatory va plus loin en vérifiant également les cookies, le CORS, les redirections et les subresource integrity (SRI).

Pour un audit professionnel, complétez avec Hardenize qui surveille en continu vos headers, certificats TLS et enregistrements DNS. Conservez des captures d’écran datées de chaque scan — elles serviront de preuve de conformité pour vos audits NIS2 et vos assureurs cyber.

Étape 3 : Configurer Content-Security-Policy (CSP)

Le CSP est le header le plus puissant et le plus complexe. Il définit les sources autorisées pour chaque type de ressource : scripts, styles, images, fonts, connexions XHR. Un CSP strict bloque les scripts inline non autorisés, neutralisant la majorité des attaques XSS.

Commencez impérativement en mode report-only : Content-Security-Policy-Report-Only: default-src ’self’; script-src ’self’; report-uri /csp-report. Surveillez les violations pendant 1 à 2 semaines avant de passer en mode enforcement. Chaque violation rapportée est soit un faux positif à whitelister, soit une tentative d’injection à bloquer.

Pour Nginx, ajoutez dans votre bloc server : add_header Content-Security-Policy "default-src ’self’; script-src ’self’ https://cdn.trusted.com; style-src ’self’ ’unsafe-inline’; img-src ’self’ data: https:; font-src ’self’ https://fonts.gstatic.com;" always;. Pour Apache, utilisez la directive Header always set Content-Security-Policy "..." dans votre .htaccess ou configuration VirtualHost.

Étape 4 : Déployer Strict-Transport-Security (HSTS)

HSTS force le navigateur à utiliser exclusivement HTTPS pour votre domaine pendant une durée définie. Sans HSTS, un attaquant sur le même réseau WiFi peut intercepter la première requête HTTP avant la redirection vers HTTPS (attaque SSL stripping). La configuration recommandée est Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

Le paramètre max-age=31536000 correspond à 1 an. Le flag includeSubDomains étend la politique à tous les sous-domaines. Et preload vous permet de soumettre votre domaine à la liste de préchargement HSTS intégrée dans Chrome, Firefox, Safari et Edge via hstspreload.org.

Étape 5 : Vérifier X-Frame-Options et X-Content-Type-Options

X-Frame-Options: DENY empêche votre site d’être intégré dans un iframe, bloquant les attaques de clickjacking. Si vous devez autoriser l’intégration sur votre propre domaine, utilisez SAMEORIGIN. Notez que la directive CSP frame-ancestors remplace progressivement X-Frame-Options, mais les deux restent recommandés pour la compatibilité avec les anciens navigateurs.

X-Content-Type-Options: nosniff empêche le navigateur de deviner le type MIME des ressources (MIME sniffing). Sans ce header, un fichier texte contenant du JavaScript pourrait être exécuté comme un script. La configuration est simple et universelle — il n’y a aucune raison de ne pas l’activer.

Étape 6 : Configurer Permissions-Policy

Permissions-Policy (anciennement Feature-Policy) contrôle quelles API du navigateur sont accessibles par votre site et les iframes intégrés. Désactivez systématiquement les fonctionnalités non utilisées : Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(self).

En 2026, les APIs sensibles incluent également interest-cohort (Topics API, successeur de FLoC), attribution-reporting, browsing-topics et shared-storage. Désactivez-les si vous n’utilisez pas la Privacy Sandbox de Chrome. Cela protège vos utilisateurs contre le tracking par des scripts tiers injectés dans vos pages.

Étape 7 : Optimiser Referrer-Policy et headers supplémentaires

Referrer-Policy: strict-origin-when-cross-origin est le meilleur compromis entre sécurité et fonctionnalité. Il envoie l’URL complète pour les requêtes same-origin mais uniquement l’origine (sans le path) pour les requêtes cross-origin. Cela protège les URLs sensibles (tokens, identifiants de session dans l’URL) tout en préservant les analytics.

N’oubliez pas les headers supplémentaires. Cross-Origin-Opener-Policy: same-origin isole votre page des fenêtres ouvertes par vos liens. Cross-Origin-Embedder-Policy: require-corp empêche le chargement de ressources cross-origin sans autorisation explicite. Ces deux headers sont nécessaires pour activer SharedArrayBuffer et les APIs haute performance.

Étape 8 : Mettre en place un monitoring continu

Un audit ponctuel ne suffit pas. Les headers peuvent changer après une mise à jour du serveur, un déploiement applicatif ou une modification de la configuration CDN. Mettez en place un monitoring automatisé qui vérifie quotidiennement la présence et la valeur de vos headers critiques.

Configurez un endpoint /csp-report pour collecter les violations CSP en temps réel. Chaque violation est un signal : soit un script légitime à whitelister, soit une tentative d’injection à investiguer. Intégrez ces rapports dans votre SIEM pour corréler avec d’autres indicateurs de compromission. Des outils comme Report URI ou Sentry CSP offrent une interface dédiée pour analyser et trier les violations.

Enfin, intégrez la vérification des headers dans votre pipeline CI/CD. Un test automatisé qui vérifie la présence de tous les headers requis après chaque déploiement est la meilleure protection contre les régressions. Utilisez des bibliothèques comme helmet pour Node.js ou django-csp pour Python afin de centraliser la gestion des headers dans votre code applicatif, comme nous le détaillons dans notre guide sur la sécurisation des applications JavaScript.

Questions fréquentes

Quels sont les headers HTTP de sécurité les plus importants ?

Les headers les plus critiques sont Content-Security-Policy (CSP), Strict-Transport-Security (HSTS), X-Frame-Options, X-Content-Type-Options, Permissions-Policy et Referrer-Policy. CSP et HSTS sont les deux plus impactants pour la sécurité de votre site.

Comment tester rapidement mes headers HTTP de sécurité ?

Utilisez securityheaders.com pour un scan instantané avec notation A-F, ou curl -I votre-domaine.com en ligne de commande. Pour un audit approfondi, combinez Mozilla Observatory, Hardenize et les DevTools de votre navigateur.

La mise en place d’un CSP peut-elle casser mon site ?

Oui, un CSP mal configuré peut bloquer des scripts, images ou styles légitimes. Commencez toujours en mode Content-Security-Policy-Report-Only pour observer les violations sans bloquer, puis passez progressivement en mode enforcement après correction.

Quelle note faut-il viser sur securityheaders.com ?

Visez la note A minimum. En 2026, un site professionnel sans au moins une note A sur securityheaders.com présente des lacunes de sécurité significatives. La note A+ est atteignable et recommandée pour les sites traitant des données sensibles.