Les en-têtes de réponse HTTP indiquent au navigateur comment traiter vos pages : quels scripts peuvent s’exécuter, si le site peut être intégré dans un cadre et s’il doit toujours être chargé en HTTPS. Une poignée d’entre eux bloquent des catégories entières d’attaques pour un coût quasi nul. D’autres sont obsolètes et n’ajoutent que du bruit, voire des risques.
Une base de départ
Voici un point de départ raisonnable pour une application HTML servie uniquement en HTTPS. Ne la collez pas telle quelle. La CSP, en particulier, doit correspondre à la manière dont vos pages chargent les scripts, son nonce doit être renouvelé à chaque réponse, et la préinscription HSTS (preload) est difficile à annuler.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: script-src 'nonce-3f9a1c7e2b' 'strict-dynamic'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-site
Content-Security-Policy
La CSP limite les sources dont peuvent provenir les scripts et les autres ressources. Son rôle principal est de rendre le cross-site scripting (XSS) beaucoup plus difficile à exploiter.
La fiche OWASP sur la CSP privilégie une politique stricte, fondée sur des nonces ou des empreintes, plutôt qu’une longue liste de domaines autorisés. Les politiques par liste blanche trop larges ou trop détaillées ont tendance à être contournées. Une politique fondée sur des nonces ressemble à ceci :
Content-Security-Policy: script-src 'nonce-3f9a1c7e2b' 'strict-dynamic'; object-src 'none'; base-uri 'none'
Chaque balise script porte alors la même valeur, comme dans <script nonce="3f9a1c7e2b">. Le nonce doit être aléatoire et renouvelé à chaque réponse ; une valeur fixe annule tout l’intérêt. Générez-le dans votre couche de templates. L’OWASP met en garde contre les middlewares qui ajoutent le nonce à toutes les balises script, car ils valideraient aussi les scripts injectés.
Si vos pages sont statiques, utilisez plutôt des empreintes : des valeurs 'sha256-...' pour chaque script en ligne. Toute modification du script, même d’un espace, change l’empreinte.
Évitez 'unsafe-inline' et 'unsafe-eval' dans script-src. Ils rouvrent exactement ce que la CSP doit fermer.
Pour déployer sans rien casser, envoyez d’abord la politique sous la forme Content-Security-Policy-Report-Only. Les navigateurs signalent alors les violations sans rien bloquer. Corrigez ce que montrent les rapports, puis passez à l’application de la politique.
Trusted Types
Les Trusted Types visent le XSS basé sur le DOM, lorsque votre propre JavaScript transmet des chaînes contrôlées par un attaquant à des API dangereuses comme innerHTML, eval() ou le src d’un élément script. On les active avec la CSP :
Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-policy
Une fois l’application activée, transmettre une simple chaîne à l’une de ces fonctions sensibles déclenche une erreur. Le code doit transmettre des valeurs créées par une politique nommée, généralement une politique qui assainit le HTML. MDN classe cette API comme Baseline depuis février 2026 : elle fonctionne donc dans les versions actuelles des principaux navigateurs. Commencez en mode report-only, car du code existant peut écrire des chaînes directement dans le DOM.
Strict-Transport-Security et preload
HSTS demande aux navigateurs de ne se connecter à votre domaine qu’en HTTPS, pendant le nombre de secondes indiqué par max-age. Avec includeSubDomains, la règle couvre aussi tous les sous-domaines.
La liste de préinscription (preload) va plus loin. Les navigateurs l’intègrent directement : même la première visite sur votre domaine se fait donc en HTTPS. Les conditions fixées sur hstspreload.org sont les suivantes :
- un certificat valide, et une redirection de HTTP vers HTTPS sur le même hôte
- tous les sous-domaines servis en HTTPS, y compris les sous-domaines internes
- un
max-aged’au moins 31536000 (un an), plusincludeSubDomainsetpreload - l’en-tête HSTS présent aussi sur les redirections servies par le site HTTPS
Déployez par étapes. Le site de préinscription suggère de commencer avec max-age=300, puis une semaine (604800), puis un mois (2592000), en surveillant les dysfonctionnements à chaque étape. Le retrait de la liste de préinscription met des mois à atteindre les utilisateurs : assurez-vous que chaque sous-domaine pourra prendre en charge HTTPS durablement.
X-Content-Type-Options
X-Content-Type-Options: nosniff empêche les navigateurs de deviner le type d’un fichier à partir de son contenu. Associez-le à un Content-Type correct sur chaque réponse, avec un charset pour le HTML, par exemple text/html; charset=UTF-8.
frame-ancestors et X-Frame-Options
Le détournement de clic (clickjacking) consiste à charger votre page de façon invisible dans un cadre sur un autre site. La directive CSP frame-ancestors contrôle qui peut vous intégrer dans un cadre, et l’OWASP relève qu’elle remplace X-Frame-Options dans les navigateurs qui la prennent en charge.
Deux détails piègent souvent. Selon MDN, frame-ancestors ne se rabat pas sur default-src : vous devez donc la définir explicitement. Elle n’a pas non plus d’effet dans une balise <meta> ; elle ne fonctionne que sous forme d’en-tête. Pour les navigateurs plus anciens, envoyer les deux ne fait pas de mal :
Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY
Utilisez frame-ancestors 'self' si votre propre site intègre ses pages dans des cadres. Évitez X-Frame-Options: ALLOW-FROM, qui est obsolète. MDN précise que les navigateurs modernes ignorent alors l’en-tête tout entier.
Referrer-Policy
Cet en-tête contrôle la part de l’URL courante transmise aux autres sites dans l’en-tête Referer. Si vous ne définissez rien, les navigateurs appliquent par défaut strict-origin-when-cross-origin, qui n’envoie que l’origine aux autres sites en HTTPS. L’OWASP recommande néanmoins de le définir explicitement. Utilisez no-referrer ou same-origin si vos URL peuvent contenir des jetons ou des données personnelles.
Permissions-Policy
Permissions-Policy désactive les fonctions du navigateur que votre site n’utilise pas. Une liste d’autorisation vide, (), désactive une fonction pour votre page et pour tous les cadres qu’elle contient :
Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=()
Si une fonction est nécessaire, autorisez-la de façon restreinte, par exemple camera=(self).
COOP et CORP
Cross-Origin-Opener-Policy: same-origin place votre page dans son propre groupe de contextes de navigation. Une page qui ouvre la vôtre avec window.open() ne peut alors pas en conserver une référence, ce qui ferme la porte à une catégorie d’attaques par fuite intersites (XS-Leaks). Si vous utilisez des fenêtres pop-up pour l’authentification unique ou les paiements, same-origin-allow-popups leur permet de continuer à fonctionner.
Cross-Origin-Resource-Policy: same-site empêche d’autres sites d’intégrer vos ressources, comme les images ou les scripts. Cross-Origin-Embedder-Policy: require-corp n’est nécessaire que pour l’isolement cross-origin, qu’exigent des fonctions comme SharedArrayBuffer. N’ajoutez pas COEP si vous n’avez pas besoin de ces fonctions, car il bloque les ressources d’autres origines qui ne l’acceptent pas explicitement.
Les en-têtes à abandonner
| En-tête | Statut | Que faire |
|---|---|---|
X-XSS-Protection | Déprécié et non standard ; MDN prévient qu’il peut créer des failles XSS dans des sites autrement sûrs | Le supprimer, ou envoyer 0, et s’appuyer sur la CSP |
Expect-CT | Déprécié | Le supprimer |
Public-Key-Pins | Retiré de Chromium en 2018 | Le supprimer ; utiliser plutôt la Certificate Transparency et les enregistrements CAA |
X-Frame-Options: ALLOW-FROM | Obsolète | Utiliser frame-ancestors |
Server, X-Powered-By | Révèlent les logiciels et leurs versions | Les supprimer ou leur donner une valeur neutre |
Par où commencer
- Vérifiez ce qu’envoie aujourd’hui votre site avec notre analyseur d’en-têtes de sécurité.
- Ajoutez d’abord les en-têtes à faible risque :
X-Content-Type-Options,Referrer-Policy,Permissions-Policyetframe-ancestors. - Déployez HSTS avec un
max-agecourt et augmentez-le par étapes. N’envisagez la préinscription que lorsque tous les sous-domaines sont prêts. - Faites tourner la CSP en mode report-only pendant quelques semaines, corrigez les violations, puis appliquez-la.
Si vous développez une nouvelle application et souhaitez intégrer ces protections dès la conception, notre équipe de développement sécurisé peut vous aider.
