En-têtes de sécurité : le rôle de chacun et comment les configurer

En bref : les en-têtes de sécurité sont des instructions que votre serveur envoie avec chaque page pour demander aux navigateurs de toujours utiliser HTTPS, de n'exécuter que les scripts provenant de sources approuvées, de refuser que d'autres sites affichent vos pages dans un cadre, de ne jamais deviner les types de fichiers et de ne pas exposer les URL complètes dans l'en-tête Referer. Commencez par HTTPS partout avec un certificat valide, puis ajoutez Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin et frame-ancestors ou X-Frame-Options. Déployez Content-Security-Policy d'abord en mode report-only. Tous se définissent dans la configuration du serveur ou du CDN.

Les en-têtes de sécurité sont une assurance peu coûteuse. La plupart tiennent en une ligne de configuration serveur, n'ont aucun coût en performance et ferment des familles entières d'attaques : un script injecté qui vole des sessions, un cadre invisible qui pousse à cliquer, un réseau de café qui rétrograde un visiteur en HTTP simple. Ce sont aussi parmi les premiers points vérifiés par les scanners de sécurité, les clients grands comptes et les questionnaires de sécurité.

Ce guide explique chaque en-tête et les bases de la connexion qui les entourent, donne des valeurs de départ sûres, montre comment notre vérificateur d'en-têtes de sécurité gratuit teste votre site, et détaille la correction de chaque problème signalé.

Les bases d'abord : HTTPS, certificat et contenu mixte

Les en-têtes s'appuient sur une connexion chiffrée ; sans elle, ils ne servent à rien. Trois bases passent en premier :

• HTTPS sur chaque page, avec redirection depuis HTTP. Depuis Chrome 68 en juillet 2018, Chrome signale toute page HTTP comme « non sécurisée » (Chromium Blog), et les recommandations de Google sur l'expérience de page demandent : « Are your pages served in a secure fashion? »
• Un certificat valide qui couvre tous les noms d'hôte utilisés, y compris www et le domaine nu. Un certificat expiré ou non concordant affiche un avertissement en pleine page.
• Aucun contenu mixte. Une page sécurisée qui charge des fichiers en http:// n'est pas totalement sécurisée. Selon MDN, les navigateurs mettent automatiquement à niveau les images, l'audio et la vidéo vers HTTPS, et bloquent purement et simplement les scripts, feuilles de style, iframes et autres contenus « bloquables », ce qui casse la page.

Les en-têtes, un par un

Strict-Transport-Security (HSTS)

HSTS indique au navigateur d'utiliser HTTPS pour votre hôte pendant un nombre de secondes donné, même lorsque quelqu'un tape http:// ou clique sur un ancien lien. MDN signale trois points à connaître :

• Les navigateurs ignorent l'en-tête lorsqu'il arrive en HTTP simple. Envoyez-le sur les réponses HTTPS ; votre redirection HTTP vers HTTPS n'en a pas besoin.
• Il ne fonctionne qu'après la première visite sécurisée. Le preload comble cette lacune.
• includeSubDomains applique la politique à tous les sous-domaines : vérifiez-les tous d'abord.

La liste HSTS preload inscrit votre domaine en dur dans les navigateurs. Elle exige un certificat valide, une redirection HTTP vers HTTPS sur le même hôte, tous les sous-domaines en HTTPS, et un en-tête avec max-age d'au moins 31536000, includeSubDomains et preload. Elle avertit aussi que « inclusion in the preload list cannot easily be undone » : un retrait met des mois à atteindre les utilisateurs. N'activez le preload que si vous êtes certain.

Content-Security-Policy (CSP)

La CSP est le plus puissant des en-têtes et le plus difficile à déployer. Elle liste les origines autorisées pour charger scripts, styles, images et autres ressources, et le navigateur refuse tout le reste. MDN la décrit principalement comme « a defense against cross-site scripting (XSS) attacks ».

La forme moderne recommandée est une CSP stricte fondée sur des nonces ou des hachages plutôt que sur de longues listes blanches de domaines :

Content-Security-Policy: script-src 'nonce-{RANDOM}'; object-src 'none'; base-uri 'none'

Le nonce doit être aléatoire et différent à chaque réponse. MDN prévient que 'unsafe-inline' « defeats much of the purpose of having a CSP ».

Comme une politique stricte peut casser des balises d'analytics, des widgets de chat et des scripts inline, déployez-la en deux étapes : envoyez Content-Security-Policy-Report-Only avec un point de collecte des rapports, corrigez ce que les rapports révèlent, puis passez à l'en-tête en mode application. C'est aussi dans la CSP que se trouve upgrade-insecure-requests (un filet de sécurité contre le contenu mixte, pas un remplacement de HSTS) et que frame-ancestors contrôle l'affichage en cadre.

X-Frame-Options et frame-ancestors

Le clickjacking charge votre page dans un cadre invisible sur un autre site et incite à cliquer sur vos boutons. Deux moyens de l'empêcher :

• X-Frame-Options: SAMEORIGIN (ou DENY), l'ancien en-tête. ALLOW-FROM est obsolète et fait que les navigateurs modernes ignorent l'en-tête.
• Content-Security-Policy: frame-ancestors 'self', l'option la plus flexible, qui peut aussi lister des origines partenaires précises.

Aucun des deux ne fonctionne depuis une balise <meta>. MDN indique que X-Frame-Options dans un élément meta « has no effect » et que frame-ancestors « is not supported in the <meta> element ». Notez aussi que frame-ancestors ne retombe pas sur default-src : une politique default-src 'none' autorise quand même n'importe qui à afficher la page dans un cadre.

X-Content-Type-Options

nosniff demande aux navigateurs de faire confiance à votre en-tête Content-Type. Avec lui, une réponse demandée comme script ou feuille de style est bloquée si son type MIME ne correspond pas, ce qui empêche un fichier téléversé déguisé en image de s'exécuter comme script. Il n'a qu'une seule valeur valide :

X-Content-Type-Options: nosniff

Assurez-vous que votre serveur envoie les bons types de contenu, surtout pour JavaScript et CSS, avant de l'ajouter.

Referrer-Policy

Quand un visiteur clique sur un lien vers un autre site, le navigateur envoie un en-tête Referer. Les navigateurs modernes utilisent déjà par défaut strict-origin-when-cross-origin, qui n'envoie que l'origine (https://example.com/) entre sites et rien en passant de HTTPS à HTTP (MDN). OWASP recommande tout de même de le définir explicitement « rather than relying on browser defaults ». Évitez unsafe-url, qui envoie partout les URL complètes, jetons compris.

Permissions-Policy, et les en-têtes à supprimer

Permissions-Policy désactive les fonctionnalités du navigateur que vous n'utilisez pas, afin qu'un script intégré ne puisse pas demander la caméra ou la localisation. MDN la classe comme expérimentale avec un support navigateur limité : voyez-y une couche supplémentaire. Notre vérificateur gratuit ne la teste pas ; l'analyse de sécurité complète, si.

Deux en-têtes à retirer plutôt qu'à ajouter : OWASP déconseille de définir X-XSS-Protection (ou de le mettre à 0), car les anciens filtres qu'il contrôlait pouvaient créer des vulnérabilités, et juge Expect-CT obsolète. Il recommande aussi de supprimer X-Powered-By et de donner à Server une valeur non informative.

Comment fonctionne le vérificateur d'en-têtes de sécurité Searvia

Le vérificateur d'en-têtes de sécurité gratuit utilise le même moteur que notre vérificateur SEO de site web et place cinq contrôles en tête. Il effectue des requêtes ordinaires que n'importe quel visiteur pourrait faire ; rien n'est attaqué ni sondé.

Les trois comptabilisés sont Content-Security-Policy, X-Frame-Options (ou un en-tête CSP contenant frame-ancestors) et X-Content-Type-Options. Referrer-Policy est aussi listé, mais son absence n'est pas retenue contre vous : les navigateurs utilisent déjà strict-origin-when-cross-origin par défaut, et le tableau le précise. Le tableau de résultats affiche la valeur de chacun, les longues politiques étant raccourcies.

Quelques limites à garder en tête :

• Il vérifie la présence, pas la qualité. Une CSP pleine de 'unsafe-inline' passe ici ; l'analyse de sécurité complète la note.
• Il lit les en-têtes de réponse HTTP. Une CSP définie dans une balise <meta> est prise en compte, avec une note : frame-ancestors et les rapports n'y fonctionnent pas, elle ne peut donc pas remplacer X-Frame-Options. Un en-tête Content-Security-Policy-Report-Only ne compte pas comme politique appliquée.
• Il vérifie une seule page, celle que vous saisissez (la page d'accueil si vous ne saisissez qu'un domaine). D'autres chemins, comme une zone d'administration ou une API, peuvent envoyer des en-têtes différents.
• Le contenu mixte n'est détecté que dans le HTML : URL absolues http:// dans les balises. Les fichiers demandés plus tard par le CSS ou le JavaScript ne sont pas vus.

Comment lire les résultats

Travaillez de haut en bas selon la priorité. Un échec du contrôle HTTPS ou du certificat est urgent : les visiteurs voient des avertissements du navigateur ou circulent sans chiffrement. Le contenu mixte actif (scripts, iframes, feuilles de style) vient ensuite, car les navigateurs bloquent ces fichiers et la page peut se casser. HSTS et les en-têtes de sécurité ont une priorité basse dans le score, mais ce sont aussi les plus rapides à corriger : regroupez-les dans une seule modification de configuration.

Comment corriger chaque problème signalé par le vérificateur

« The site does not work over HTTPS. » / « HTTP does not redirect to HTTPS. »

1. Installez un certificat. Let's Encrypt est gratuit et la plupart des hébergeurs le proposent en un clic.
2. Ajoutez une redirection permanente de chaque URL http:// vers la même URL https://.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Sur Cloudflare, activez « Always Use HTTPS » sous SSL/TLS › Edge Certificates.

« The certificate expired N days ago. » / « The certificate does not cover this domain. »

1. Renouvelez-le tout de suite et activez le renouvellement automatique (Certbot et la plupart des hébergeurs et CDN le font par défaut).
2. Vérifiez que le certificat liste chaque nom d'hôte que vous servez, au minimum le domaine nu et www.
3. Si le renouvellement échoue en silence, les causes habituelles sont un enregistrement DNS modifié, un chemin de validation bloqué ou un jeton d'API expiré pour la validation DNS.

Un avertissement avec moins de 14 jours restants signifie généralement que le renouvellement automatique ne fonctionne pas ; cherchez la cause plutôt que de renouveler à la main à chaque fois.

« HSTS is not set. » / « HSTS is on but shorter than 6 months. »

Déployez-le par étapes pour qu'un sous-domaine oublié, uniquement en HTTP, ne se retrouve pas bloqué :

1. Vérifiez que le site principal et chaque sous-domaine fonctionnent en HTTPS.
2. Envoyez Strict-Transport-Security: max-age=300 pendant un jour, puis une semaine (604800), puis un mois.
3. Passez à max-age=31536000; includeSubDomains.
4. Seulement ensuite, envisagez preload et soumettez sur hstspreload.org.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

« N files load over plain HTTP. »

1. Ouvrez la liste des URL dans le rapport.
2. Remplacez chacune par https://, ou par un chemin relatif pour vos propres fichiers. Pour les fichiers tiers, vérifiez que le fournisseur sert en HTTPS ; sinon, changez de fournisseur.
3. Cherchez dans votre base de données et votre thème les liens http:// codés en dur ; après une migration vers HTTPS, le contenu des anciens articles en est la source habituelle.
4. Comme filet de sécurité, ajoutez Content-Security-Policy: upgrade-insecure-requests.

« N key security headers are missing. »

Ajoutez les manquants en une seule modification. Pour nginx :

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'self'; report-to csp" always;

Pour Apache :

Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

Sur Cloudflare, ajoutez des en-têtes de réponse avec une Transform Rule. Sur Netlify, utilisez un fichier _headers ; sur Vercel, le paramètre headers de vercel.json. Dans nginx, rappelez-vous qu'un add_header dans un bloc location remplace les en-têtes définis au niveau du serveur : répétez-les ou utilisez un fichier d'inclusion.

Pour la CSP, la ligne report-only ci-dessus est un point de départ, pas une politique aboutie. Pointez report-to vers un point de collecte que vous contrôlez, examinez les violations pendant une à deux semaines, ajustez la politique, puis renommez l'en-tête en Content-Security-Policy. Une fois appliquée, le contrôle CSP passe.

Comment vérifier vous-même les en-têtes

Le vérificateur montre ce qu'envoie la page testée, mais d'autres pages, fichiers et réponses d'erreur peuvent différer. Deux moyens rapides de regarder :

• Les DevTools du navigateur. Ouvrez le panneau Network, rechargez la page, cliquez sur la première requête et lisez la section Response Headers.
• La ligne de commande. curl -sI https://www.example.com/ n'affiche que les en-têtes de réponse. Lancez-la pour la page d'accueil, une page profonde, un PDF, une page 404 et votre page de connexion.

Une surprise fréquente : des en-têtes présents sur les pages normales mais absents des erreurs ou des redirections. Dans nginx, add_header ne s'applique qu'aux réponses réussies et aux redirections, sauf si vous ajoutez le paramètre always, c'est pourquoi chaque exemple ci-dessus l'inclut. Autre piège : un CDN ou un hébergeur qui ajoute ou supprime des en-têtes ; vérifiez donc la réponse que voit le public, pas seulement votre fichier de configuration serveur.

Gardez en tête que chaque en-tête protège une chose différente. Une CSP parfaite ne change rien à un certificat expiré, et HSTS ne change rien face à un script injecté. L'objectif est l'ensemble complet, ajouté dans un ordre sensé.

Exemple pratique (hypothétique)

Ce qui suit est un exemple hypothétique, pas des données réelles. Halden Legal, un cabinet d'avocats fictif, reçoit d'un client grand compte un questionnaire de sécurité portant sur les en-têtes de son site. Le vérificateur d'en-têtes de sécurité indique :

• HTTPS, certificat TLS : réussite, 61 jours restants.
• HSTS : avertissement, max-age=86400 (un jour).
• Contenu mixte : avertissement, 2 images chargées en HTTP (un badge partenaire et une ancienne photo d'équipe).
• En-têtes de sécurité : 2 en-têtes clés manquants ; seul X-Content-Type-Options est défini, et Referrer-Policy affiche la valeur par défaut du navigateur.

Les corrections prennent un après-midi. Les deux URL d'images passent en HTTPS. Après avoir confirmé que le sous-domaine du portail client fonctionne en HTTPS, HSTS passe à max-age=31536000; includeSubDomains en deux étapes sur une semaine. X-Frame-Options: SAMEORIGIN et Referrer-Policy: strict-origin-when-cross-origin sont ajoutés au niveau du serveur. Une CSP en report-only tourne pendant dix jours et révèle un script inline du widget de réservation, déplacé dans un fichier et autorisé par son origine avant l'application de la politique. La dernière analyse passe tous les contrôles, et le cabinet répond au questionnaire avec un lien vers le rapport partagé.

Une checklist d'une heure

1. Lancez le vérificateur d'en-têtes de sécurité et corrigez d'abord les échecs HTTPS et certificat.
2. Supprimez le contenu mixte listé dans le rapport.
3. Ajoutez X-Content-Type-Options, Referrer-Policy et X-Frame-Options ou frame-ancestors.
4. Montez HSTS par étapes jusqu'à un an une fois que chaque sous-domaine fonctionne en HTTPS.
5. Lancez une CSP en report-only et planifiez une revue.
6. Supprimez X-Powered-By, les numéros de version dans Server, et tout X-XSS-Protection autre que 0.

Comment Searvia surveille la sécurité de votre site

Le vérificateur d'en-têtes de sécurité gratuit analyse votre page d'accueil, ou n'importe quelle page saisie, en environ 20 secondes, sans inscription, et le même rapport couvre 33 contrôles supplémentaires sur l'apparence dans les résultats de recherche, le crawl, la vitesse, le mobile et l'authentification des e-mails.

Un compte Searvia gratuit ajoute une analyse de sécurité hebdomadaire : contrôles passifs du chiffrement, des protections du navigateur, des attributs de cookies, des versions de logiciels et de la protection contre l'usurpation d'e-mail, avec la requête et la réponse qui prouvent chaque constat. Elle note votre CSP (par exemple 'unsafe-inline' sans nonces ni hachages), vérifie Permissions-Policy et, une fois que vous avez vérifié la propriété, recherche aussi des fichiers .env et .git exposés, des sauvegardes publiques, des pages de debug et du CORS non sécurisé. Write the remediation plan with AI transforme les constats en configuration à copier-coller (5 crédits). Sur les offres payantes à partir de Starter, la surveillance de disponibilité vérifie aussi chaque jour votre certificat TLS et vous alerte avant son expiration.