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

Les en-têtes de sécurité constituent le renforcement technique le plus accessible et le plus économique pour un site web. Chacun correspond à une simple ligne de configuration serveur, n'a aucun impact sur les performances et neutralise des catégories entières de cyberattaques.

Pourtant, la majorité des sites n'en transmettent aucun.

Voici le rôle exact de chacun, leur ordre de déploiement recommandé et les deux en-têtes obsolètes qu'il faut impérativement supprimer.

Par où commencer : les trois en-têtes sans aucun risque

Ces trois en-têtes peuvent être déployés immédiatement sur n'importe quel site web, sans risque de dysfonctionnement.

X-Content-Type-Options: nosniff

X-Content-Type-Options: nosniff

Une valeur unique, aucune configuration supplémentaire, aucun effet secondaire négatif.

Sans cet en-tête, les navigateurs tentent de « deviner » (sniffing) le type MIME d'un fichier et peuvent décider que sa nature réelle diffère de celle déclarée par le serveur. C'est le vecteur d'attaque permettant à un fichier téléversé par un utilisateur — déclaré comme une image — d'être exécuté comme du JavaScript parce que son contenu ressemble à un script.

Il n'existe aucune raison valable de ne pas envoyer cet en-tête. S'il manque sur votre site, c'est le premier correctif à appliquer.

X-Frame-Options

X-Frame-Options: SAMEORIGIN

Cet en-tête empêche vos pages d'être intégrées dans une iframe sur un site tiers. C'est la parade directe contre le détournement de clic (clickjacking) : un attaquant charge votre page dans un cadre invisible placé sous un faux bouton attractif, détournant le clic de la victime vers votre interface d'administration ou de paiement.

La directive SAMEORIGIN autorise votre propre domaine à intégrer ses pages, ce qui est le comportement souhaité dans la quasi-totalité des cas. DENY bloque toute intégration dans un cadre.

Son successeur moderne est la directive frame-ancestors de la CSP, plus fine et plus souple. Déployer les deux ne coûte rien et assure la compatibilité avec les anciens navigateurs.

Referrer-Policy

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

Définit quelle portion de l'URL courante est transmise dans les en-têtes HTTP lorsqu'un visiteur clique sur un lien externe.

Sans cet en-tête, l'URL complète est transmise — y compris les éventuels paramètres de requête (query string). Des jetons de réinitialisation de mot de passe, des identifiants de session ou des données personnelles ont fréquemment fuité vers des services tiers par ce biais.

strict-origin-when-cross-origin transmet l'URL complète lors de la navigation interne, uniquement le nom de domaine racine vers les sites externes en HTTPS, et aucune information lors d'un passage vers du HTTP non chiffré. C'est désormais le comportement par défaut des navigateurs modernes, mais le déclarer explicitement garantit son application universelle.

Étape suivante : HSTS

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

Indique au navigateur de communiquer avec votre domaine exclusivement via HTTPS, pour toute la durée spécifiée, sans jamais tenter de connexion HTTP non sécurisée.

Deux avantages majeurs : sur le plan de la sécurité, il élimine la fenêtre de vulnérabilité où une requête initiale en HTTP pourrait être interceptée (attaque de type Man-in-the-Middle) avant votre redirection. Sur le plan des performances, il supprime totalement la redirection 301 http→https pour les visiteurs réguliers, économisant un aller-retour réseau complet à chaque affichage de page.

Déployez-le avec rigueur. Le HSTS est un engagement strict que le navigateur mémorise et qu'il est difficile de révoquer rapidement. Si vous définissez un max-age d'un an avec includeSubDomains et réalisez ensuite qu'un sous-domaine interne ne supporte que le HTTP, ce dernier sera totalement inaccessible pour tous vos visiteurs récents — et ce jusqu'à expiration du délai.

La méthode de déploiement sécurisée :

1. Vérifier que tous les sous-domaines fonctionnent parfaitement en HTTPS.
2. Déployer avec max-age=300 (5 minutes) pendant quelques jours d'observation.
3. Augmenter à max-age=86400 (1 jour) pendant une semaine.
4. Appliquer enfin max-age=31536000; includeSubDomains (1 an).

La directive preload permet d'inscrire directement votre domaine dans la liste native des navigateurs. Son retrait pouvant prendre plusieurs mois, ne l'activez qu'une fois votre infrastructure HTTPS définitivement éprouvée.

La pièce maîtresse : Content-Security-Policy (CSP)

La CSP (Content Security Policy) déclare les sources autorisées depuis lesquelles la page a le droit de charger des scripts, styles, images, polices ou d'établir des connexions réseau. Lorsqu'elle est correctement paramétrée, elle neutralise l'essentiel des attaques par injection de code (XSS) : même si un script malveillant parvient à être injecté, le navigateur refuse de l'exécuter car son origine n'est pas autorisée.

C'est aussi le seul en-tête de cette liste qui peut bloquer des fonctionnalités légitimes en cas d'erreur, ce qui explique sa faible adoption.

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'self'; base-uri 'self'; form-action 'self'

Le compromis de unsafe-inline. De nombreux sites intègrent des balises <script> directement dans leur code HTML (tags d'analyse d'audience, gestionnaires de balises). Une CSP stricte les bloque toutes par défaut. Ajouter 'unsafe-inline' à script-src permet d'éviter les blocages mais annule la majeure partie de la protection contre les failles XSS.

La solution pérenne repose sur les jetons cryptographiques à usage unique (nonces) ou les empreintes de hachage : le serveur génère un nonce aléatoire par requête, l'insère dans vos scripts légitimes et le déclare dans l'en-tête CSP. Cela requiert toutefois une génération dynamique côté serveur.

Déployez d'abord en mode audit (Report-Only) :

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

Aucun élément n'est bloqué ; les violations constatées sont envoyées à votre serveur pour analyse. Laissez tourner ce mode 2 à 4 semaines, autorisez les sources légitimes identifiées, puis basculez l'en-tête en mode actif (Content-Security-Policy).

Quatre directives simples et très rentables même sur une politique souple : frame-ancestors (anti-clickjacking), base-uri (empêche la modification de l'URL de base), form-action (interdit l'envoi de formulaires vers des domaines non autorisés) et object-src 'none' (bloque les anciens plugins de type Flash).

Permissions-Policy

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

Déclare les fonctionnalités matérielles et logicielles du navigateur que votre page s'autorise à utiliser. Désactiver explicitement ce dont vous n'avez pas l'utilité limite ce qu'un script tiers compromis pourrait exploiter. Si votre site ne sollicite jamais la caméra ou le micro, le déclarer ne coûte rien et protège immédiatement vos visiteurs.

Deux en-têtes à supprimer impérativement

X-XSS-Protection est obsolète. Il activait un filtre anti-XSS historique dans les navigateurs, supprimé de Chrome et Edge car son mécanisme introduisait lui-même de nouvelles failles de sécurité. Le conserver ne sert à rien et signale une configuration ancienne copiée sans mise à jour.

Server et X-Powered-By diffusent publiquement les technologies et numéros de version précis de votre serveur web (PHP, Apache, etc.). Lors de la découverte d'une nouvelle faille zero-day, les robots de scan automatisés recherchent ces signatures. Supprimez-les :

Header unset X-Powered-By
Header unset Server
ServerTokens Prod

Configuration pour Apache et LiteSpeed

Cette configuration s'applique à la plupart des hébergements mutualisés et cPanel, y compris Hostinger. Dans votre fichier .htaccess :

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS
  Header unset X-Powered-By
</IfModule>

Le mot-clé always est déterminant : sans lui, les en-têtes ne sont pas transmis lors des réponses d'erreur HTTP (404, 500), moment où leur présence est pourtant tout aussi indispensable.

Sur Nginx, la syntaxe équivalente s'effectue via add_header … always; au sein du bloc server.

Vérification de votre infrastructure

Vous pouvez analyser les en-têtes HTTP de n'importe quel site grâce à notre scanner d'en-têtes de sécurité gratuit. Il interroge votre serveur en direct, analyse les directives et met en évidence les faiblesses avec des recommandations précises.

Ordre de déploiement recommandé

1. X-Content-Type-Options — une ligne, aucun risque
2. X-Frame-Options — une ligne, aucun risque
3. Referrer-Policy — une ligne, aucun risque
4. Supprimer X-XSS-Protection et les en-têtes de versionning logiciel
5. Permissions-Policy — interdire les fonctionnalités superflues
6. HSTS — déploiement progressif par paliers de durée
7. CSP — en mode Report-Only, puis passage en application stricte

Les étapes 1 à 5 s'exécutent en un seul déploiement en moins d'une heure. Les étapes 6 et 7 demandent un suivi. Appliquer les cinq premières vous place déjà au-dessus du niveau de sécurité de la grande majorité du web.

Une précision utile : ces en-têtes ne constituent pas un critère direct de positionnement SEO. En revanche, un site piraté et signalé par Google perd l'intégralité de sa visibilité en quelques heures — réparer un dommage de réputation coûte infiniment plus cher que d'ajouter quelques lignes de configuration serveur préventives.