En-têtes de sécurité HTTP : comprendre CSP, HSTS et les autres

Votre application est en ligne. Les pages se chargent, les formulaires fonctionnent et rien ne semble défectueux. Pourtant, un scan signale plusieurs problèmes d’en-têtes HTTP dont la signification n’est pas évidente.

C’est une réaction fréquente : les en-têtes ne sont pas visibles sur la page. Il est donc difficile de comprendre leur utilité. Ce guide explique les principaux en-têtes de sécurité et la manière de vérifier leur configuration.

Les en-têtes de sécurité sont des instructions envoyées par le serveur au navigateur avec la page. Ils déterminent notamment les scripts autorisés, l’utilisation de HTTPS et la possibilité d’intégrer une page dans un autre site.

Leur absence ne modifie pas forcément l’apparence du site. Celui-ci peut fonctionner normalement tout en étant privé de protections qui deviennent importantes face à une attaque.

Les en-têtes réduisent certains risques ; ils ne suffisent pas à sécuriser une application. Un contrôle sans anomalie ne garantit donc pas la sécurité globale du site. Ils constituent néanmoins une couche de protection souvent peu coûteuse à mettre en place.

Lorsqu’un navigateur demande une page, le serveur renvoie son contenu et des métadonnées appelées en-têtes de réponse. Pour les consulter, ouvrez les outils de développement, sélectionnez l’onglet Réseau, rechargez la page et ouvrez la requête du document.

Les en-têtes de sécurité demandent au navigateur d’appliquer des règles. Ils se configurent principalement sur le serveur, dans le framework ou chez l’hébergeur. Certains mécanismes, comme une partie de CSP, disposent aussi d’un équivalent HTML avec des limites.

CSP définit les sources de contenu autorisées sur une page. C’est un mécanisme puissant, mais sa configuration doit être adaptée à votre application.

Une politique peut autoriser les scripts de votre domaine et d’un CDN approuvé, les images servies en HTTPS, et interdire l’intégration de la page dans un autre site. Les ressources qui ne respectent pas les règles sont bloquées lorsque la politique est appliquée.

CSP complète les protections contre les injections de scripts, notamment l’encodage des sorties et la neutralisation des contenus dangereux. Une politique trop stricte peut casser des fonctions légitimes. Commencez en mode de signalement, examinez les violations, puis activez progressivement les restrictions.

HSTS indique au navigateur de contacter le domaine uniquement en HTTPS pendant une durée définie. Une fois cette instruction reçue, le navigateur transforme les requêtes HTTP en HTTPS avant de les envoyer, même si le visiteur suit un ancien lien.

La première visite peut encore commencer en HTTP si le navigateur ne connaît pas la politique. Une inscription valide dans la liste de préchargement HSTS permet de couvrir ce cas. L’en-tête seul protège les visites suivantes, après sa réception sur une connexion HTTPS.

HSTS engage le domaine pour la durée configurée. Commencez avec une durée courte, vérifiez le fonctionnement en HTTPS et, avant d’inclure les sous-domaines, assurez-vous qu’ils sont tous compatibles.

X-Frame-Options indique si un autre site peut intégrer vos pages dans un cadre HTML, par exemple dans une iframe.

Cette protection limite le détournement de clics : un attaquant peut tenter de superposer des éléments trompeurs à votre page pour provoquer une action involontaire. Les fonctions connectées, comme une suppression ou un changement de paramètres, sont particulièrement concernées.

SAMEORIGIN autorise l’intégration par des pages de la même origine. DENY interdit toute intégration. Le choix dépend de vos besoins ; la directive frame-ancestors de CSP permet également de définir les origines autorisées.

Referrer-Policy contrôle les informations de l’URL d’origine transmises lors d’une navigation ou d’une requête. Les navigateurs modernes utilisent généralement strict-origin-when-cross-origin : l’URL complète peut circuler au sein d’une même origine, mais seule l’origine est transmise vers une autre origine en HTTPS.

Des URL peuvent contenir des identifiants, des adresses e-mail, des recherches ou d’autres valeurs sensibles. Une politique trop permissive risque de les transmettre discrètement à un tiers.

Limiter les informations à l’origine, ou les supprimer pour les requêtes vers d’autres sites, permet de réduire ce risque avec peu d’impact sur le fonctionnement du site.

Quelques en-têtes supplémentaires méritent d’être connus :

• X-Content-Type-Options: nosniff évite certaines interprétations incorrectes du type d’un contenu par le navigateur.

• Permissions-Policy limite l’utilisation de fonctions comme la caméra, le microphone ou la géolocalisation.

• Cross-Origin-Opener-Policy et les mécanismes associés renforcent l’isolation entre les pages de différentes origines.

Il n’est pas nécessaire de tous les activer immédiatement. Comprendre leur rôle permet de lire un rapport et de choisir les protections adaptées.

Deux approches sont complémentaires.

Pour un contrôle manuel, ouvrez les outils de développement, l’onglet Réseau et la requête du document. Consultez les en-têtes de réponse pour confirmer leur présence et leurs valeurs.

Pour un contrôle automatisé, lancez un scan. Il relève les en-têtes présents ou absents sur les pages couvertes et explique les problèmes de configuration. Vous obtenez ainsi une liste de points à examiner, au-delà d’une seule page ouverte manuellement.

Le scan léger gratuit de VICE peut signaler des problèmes d’en-têtes parmi d’autres contrôles publics, avec les éléments observés pour comprendre chaque constat.

Les corrections se font généralement dans la configuration : serveur, framework ou interface de l’hébergeur. Modifiez un en-tête à la fois et vérifiez que les fonctions du site continuent de fonctionner.

Relancez ensuite un scan comparable. Modifier un fichier ne prouve pas que la nouvelle valeur est servie sur toutes les pages. De même, déclarer un constat corrigé ne confirme pas sa résolution : le rescan doit vérifier le résultat sur le même périmètre.

Commencez par un scan gratuit, examinez les en-têtes réellement renvoyés et traitez les constats prioritaires. Cette première vérification est plus utile que de supposer que les paramètres par défaut suffisent.