Vous subissez une attaque ? Faire appel à notre réponse aux incidents

info@angelforce.eu
Sécurité web

Les en-têtes de sécurité qui comptent, et ceux à abandonner

Guide pratique : CSP avec nonces, HSTS et preload, frame-ancestors, Referrer-Policy, Permissions-Policy, COOP, avec des exemples et ce qu’il faut retirer.

Aussi en :EnglishTürkçeDeutschEspañolItalianoPolskiNederlandsEesti

Illustration : Les en-têtes de sécurité qui comptent, et ceux à abandonner

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-age d’au moins 31536000 (un an), plus includeSubDomains et preload
  • 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êteStatutQue faire
X-XSS-ProtectionDéprécié et non standard ; MDN prévient qu’il peut créer des failles XSS dans des sites autrement sûrsLe supprimer, ou envoyer 0, et s’appuyer sur la CSP
Expect-CTDépréciéLe supprimer
Public-Key-PinsRetiré de Chromium en 2018Le supprimer ; utiliser plutôt la Certificate Transparency et les enregistrements CAA
X-Frame-Options: ALLOW-FROMObsolèteUtiliser frame-ancestors
Server, X-Powered-ByRévèlent les logiciels et leurs versionsLes supprimer ou leur donner une valeur neutre

Par où commencer

  1. Vérifiez ce qu’envoie aujourd’hui votre site avec notre analyseur d’en-têtes de sécurité.
  2. Ajoutez d’abord les en-têtes à faible risque : X-Content-Type-Options, Referrer-Policy, Permissions-Policy et frame-ancestors.
  3. Déployez HSTS avec un max-age court et augmentez-le par étapes. N’envisagez la préinscription que lorsque tous les sous-domaines sont prêts.
  4. 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.

Comment nous pouvons vous aider

Analyseur d’en-têtes de sécurité

Notez les en-têtes de sécurité, les cookies et le certificat TLS d’un site, avec une correction par constat.

Nous contacter
Équipe AngelForce

Rédigé par l’équipe AngelForce : des consultants en sécurité certifiés CEH, LPT Master et CISA qui testent, surveillent et protègent les systèmes d’organisations dans toute l’Europe et en Turquie.

Rédigé avec l’aide de l’IA à partir des sources publiques indiquées sur cette page, puis relu par l’équipe AngelForce avant publication.

Sources

  1. cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html
  2. cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
  3. hstspreload.org/
  4. developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API
  5. developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-XSS-Protection
  6. developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cross-Origin-Opener-Policy

Articles : Sécurité web

Dites-nous ce que vous devez protéger

Décrivez votre environnement et vos objectifs. Nous vous répondrons par e-mail.

Nous contacter
info@angelforce.eu

AngelForce OÜ · Tallinn, Estonie