Les en-têtes HTTP permettent au serveur de donner au navigateur des instructions de sécurité avant même que la page soit entièrement interprétée. Ils sont puissants, mais doivent être choisis en fonction du comportement réel du site.
HSTS : imposer HTTPS avec prudence
Strict-Transport-Security demande au navigateur de revenir en HTTPS pendant une durée donnée. Il est pertinent lorsque tout le site et ses sous-domaines concernés fonctionnent correctement en HTTPS. Les options longues et le preload constituent un engagement à ne pas activer à la légère.
Referrer-Policy détermine quelle partie de l’URL d’origine peut être envoyée lors d’une navigation ou d’une requête. Une politique adaptée réduit les fuites inutiles d’informations sans casser les besoins légitimes de mesure ou d’intégration.
Permissions-Policy : limiter les capacités
Cette politique permet de restreindre l’accès à certaines fonctionnalités du navigateur, par exemple caméra, microphone ou géolocalisation, selon les besoins de l’application et des iframes.
Framing et isolation
X-Frame-Options reste rencontré pour contrôler l’intégration en iframe, tandis que frame-ancestors dans CSP offre un contrôle moderne et plus fin. COOP, COEP et CORP concernent l’isolation entre origines et peuvent être nécessaires à certaines fonctionnalités avancées, mais aussi rendre des ressources tierces incompatibles.
Vérifier ce qui est réellement envoyé
Le générateur d’en-têtes de sécurité produit une base pour plusieurs environnements. L’analyseur d’en-têtes HTTP aide à lire un ensemble d’en-têtes, et le générateur d’en-têtes HTTP facilite leur construction.
Testez ensuite les réponses réelles en production. Les protections doivent être présentes sur les bonnes routes et ne pas empêcher une fonctionnalité nécessaire.
Ces en-têtes complètent la Content Security Policy ; ils ne la remplacent pas.
X-Content-Type-Options : éviter certaines interprétations inattendues
X-Content-Type-Options: nosniff demande au navigateur de respecter le type MIME déclaré pour certains chargements au lieu d’essayer d’en deviner un autre. C’est une protection simple qui suppose néanmoins que le serveur annonce correctement ses contenus.
HSTS : durée, sous-domaines et preload
Une configuration HSTS contient généralement une durée max-age. includeSubDomains étend la règle aux sous-domaines ; il faut donc vérifier qu’ils sont tous disponibles en HTTPS avant de l’activer. Le mécanisme de preload va encore plus loin en inscrivant le domaine dans une liste utilisée par les navigateurs : il est utile dans certains contextes, mais son retrait n’est pas instantané.
Commencez avec une durée prudente lors de la mise au point, puis augmentez-la une fois l’infrastructure vérifiée. HSTS ne doit pas servir à masquer un déploiement HTTPS incomplet.
Referrer-Policy : choisir le bon compromis
Une URL peut contenir des chemins ou paramètres que vous ne souhaitez pas transmettre à un autre site. Des politiques modernes comme strict-origin-when-cross-origin limitent les informations envoyées lors de navigations cross-origin tout en conservant davantage de contexte sur une même origine.
La bonne règle dépend des besoins. Surtout, ne placez jamais un secret dans une URL en comptant sur Referrer-Policy pour le protéger : historique, logs et autres intermédiaires peuvent déjà l’avoir exposé.
Permissions-Policy : n’autoriser que les capacités utiles
Caméra, microphone, géolocalisation ou certaines API puissantes n’ont aucune raison d’être disponibles partout. Permissions-Policy permet de préciser quelles origines peuvent utiliser certaines fonctionnalités, notamment dans des iframes.
C’est particulièrement intéressant pour un site intégrant du contenu tiers : une iframe nécessaire pour afficher un composant n’a pas automatiquement besoin de toutes les capacités du navigateur.
CSP et protections contre le framing
Pour les applications modernes, frame-ancestors dans CSP permet de déclarer quelles origines ont le droit d’intégrer une page. X-Frame-Options reste utile pour la compatibilité avec certains environnements, mais offre moins de finesse. Évitez les configurations contradictoires et testez les intégrations réellement utilisées.
COOP, COEP et CORP : utiles, mais pas universels
Ces en-têtes renforcent l’isolation entre contextes et ressources cross-origin. Ils peuvent être nécessaires pour certaines capacités du Web moderne, mais ils imposent aussi des contraintes aux ressources tierces. Les activer « parce qu’ils sont dans une checklist » peut casser une application.
Le bon réflexe consiste à partir du besoin fonctionnel, comprendre les conséquences, puis vérifier les réponses réelles avec l’analyseur d’en-têtes HTTP.
Construire un ensemble cohérent
Une base raisonnable associe souvent HTTPS, HSTS lorsque le domaine est prêt, nosniff, une Referrer-Policy explicite et une CSP adaptée. Permissions-Policy et les mécanismes d’isolation viennent ensuite selon les fonctionnalités.
Le nombre d’en-têtes n’est pas un score de sécurité. Une petite configuration comprise et testée vaut mieux qu’une liste copiée qui casse le site ou crée une fausse confiance.
