En-têtes de sécurité HTTP : ceux qui comptent vraiment en 2026

Votre application peut avoir une authentification irréprochable, des mots de passe correctement hachés et un rapport de pentest impeccable, et se faire compromettre par une seule balise script injectée. Les en-têtes de sécurité sont le contrat passé avec le navigateur qui limite le rayon d'explosion quand quelque chose passe entre les mailles. La plupart des équipes les ignorent, ou collent un extrait de blog de 2018 et considèrent le sujet réglé. Les deux sont des erreurs, et en 2026, l'écart entre "avoir des en-têtes" et "avoir des en-têtes qui fonctionnent" est précisément là où se produisent les incidents réels.

Pourquoi les en-têtes sont le contrôle le moins cher de votre arsenal

Un en-tête de sécurité, c'est une ligne de configuration serveur qui enrôle le navigateur de chaque visiteur comme point d'application de votre politique. Aucun agent à installer, aucun SDK, aucun coût de latence mesurable. Le navigateur refuse de charger le script de l'attaquant, refuse de rétrograder vers HTTP, refuse qu'une page hostile mette votre tunnel de paiement dans une iframe.

Le piège : les en-têtes sont une politique déclarative, et une politique que personne ne teste pourrit en silence. Nous auditons beaucoup d'applications en production chez Innovation T, et le même schéma revient sans cesse. Une Content-Security-Policy avec unsafe-inline qui s'auto-neutralise. Un en-tête HSTS présent sur le www mais absent du domaine racine. Un X-Frame-Options dupliqué trois fois par trois couches d'infrastructure, avec des valeurs contradictoires. Les en-têtes sont du code. Traitez-les comme du code : versionnés, relus, testés en CI.

Voici donc la hiérarchie que nous utilisons réellement, ce que chaque en-tête fait mécaniquement, et comment déployer les plus délicats sans casser la production.

Niveau 1 : les deux en-têtes qui bloquent de vraies attaques

Strict-Transport-Security (HSTS)

HSTS ferme la fenêtre pendant laquelle un utilisateur tape votreapp.com et le navigateur émet une première requête HTTP en clair avant la redirection. C'est dans cette première requête que vivent les proxys de SSL stripping : le Wi-Fi d'un café ou d'un hôtel, un opérateur peu scrupuleux, un portail captif d'aéroport.

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

Mécanique : dès que le navigateur voit cet en-tête sur une réponse HTTPS, il réécrit en interne toute future requête HTTP vers cette origine en HTTPS, avant même de toucher le réseau, pendant max-age secondes. Avec preload, vous pouvez soumettre le domaine à la liste de préchargement de Chromium et la protection s'applique dès la toute première visite.

Le compromis que l'on sous-estime : includeSubDomains combiné à preload est quasiment irréversible. Chaque sous-domaine que vous créerez un jour devra servir un HTTPS valide, pour toujours. Cet outil interne sur legacy.votreapp.com avec son certificat auto-signé ? Inaccessible pour tout navigateur qui a mémorisé la règle. Notre méthode : commencer avec max-age=300 pendant une semaine, puis 86400, puis une année complète, et ne soumettre au preload qu'après avoir inventorié chaque sous-domaine, y compris ceux que le marketing a créés sans prévenir personne.

Content-Security-Policy (CSP)

La CSP est le seul en-tête qui atténue réellement les attaques par cross-site scripting, et c'est celui que la plupart des équipes ratent. Une politique avec script-src 'unsafe-inline' ou une longue liste blanche de CDN relève du théâtre : les listes blanches se contournent couramment via des endpoints JSONP et des redirections ouvertes sur les domaines autorisés. L'outil CSP Evaluator de Google détecte ces failles en quelques secondes. Passez-y votre politique avant de lui faire confiance.

Ce qui fonctionne en 2026, c'est la CSP stricte construite sur des nonces et strict-dynamic :

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'self';

Mécanique : chaque balise <script> légitime porte un nonce unique par réponse. strict-dynamic signifie "tout script chargé par un script de confiance est lui-même de confiance", ce qui rend les bundlers, les imports dynamiques et la plupart des gestionnaires de tags viables. Le https: et le unsafe-inline en fin de directive sont ignorés par les navigateurs modernes et n'existent que comme filet de sécurité pour les clients antédiluviens : la politique se dégrade proprement sur les navigateurs de musée au lieu de les casser.

Deux exigences non négociables. Un, le nonce doit être cryptographiquement aléatoire à chaque réponse, ce qui signifie que votre HTML ne peut pas être mis en cache tel quel sur le CDN : il vous faut une injection de nonce en périphérie, un rendu par requête, ou une politique basée sur des hachés pour les sites entièrement statiques. Deux, frame-ancestors a sa place ici : cette directive remplace X-Frame-Options avec un contrôle plus fin et constitue la véritable défense contre le clickjacking.

La CSP est aussi votre fil de détente contre les attaques de chaîne d'approvisionnement. Quand un script tiers compromis tente d'exfiltrer des données vers un nouveau domaine, un connect-src serré transforme une fuite silencieuse en rapport de violation sur votre tableau de bord. Si vous durcissez le reste de cette chaîne, notre article sur la construction d'un pipeline DevSecOps montre où le linting d'en-têtes s'insère dans la CI.

Niveau 2 : beaucoup de valeur, très peu de risques

Ces en-têtes se déploient en quelques minutes et ne cassent presque jamais rien. Mettez-les en production cette semaine.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Empêche le navigateur de deviner les types MIME, ce qui élimine toute une classe d'attaques où une "image" téléversée est interprétée comme du script. Il est aussi requis pour que plusieurs protections modernes du navigateur s'activent pleinement. Il n'existe aucune raison légitime de l'omettre.

Referrer-Policy

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

C'est désormais la valeur par défaut des navigateurs, mais définissez-la explicitement pour qu'un proxy ou un client ancien ne puisse pas vous faire régresser. Le scénario d'échec qu'elle prévient est laid : des URL complètes, contenant parfois des jetons de réinitialisation de mot de passe ou des identifiants de session dans la chaîne de requête, qui fuient vers chaque domaine tiers dont vous chargez des ressources. Au regard du RGPD, ce type de fuite vers des tiers est une divulgation de données personnelles qu'il faudra documenter, voire notifier. Si vos URL transportent un jour des jetons sensibles, envisagez no-referrer sur ces routes spécifiquement.

Permissions-Policy

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

Du refus par défaut pour les API puissantes du navigateur. L'enjeu n'est pas que votre code demande soudainement l'accès à la caméra. L'enjeu est qu'un script tiers compromis, embarqué sur votre page, hérite de vos permissions. Refuser tout ce que vous n'utilisez pas transforme "un attaquant dans une iframe publicitaire active les capteurs" en non-événement. Bonus : browsing-topics=() retire vos utilisateurs des API de ciblage par centres d'intérêt, un petit gain de confiance qui va dans le sens du RGPD et des attentes de la CNIL.

Le trio d'isolation cross-origin : COOP, COEP, CORP

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-site

Ces en-têtes existent à cause des attaques de type Spectre : toute donnée chargée dans votre processus peut potentiellement être lue par du code attaquant s'exécutant dans le même processus. COOP coupe la référence de fenêtre entre votre page et les pages qui l'ouvrent, ce qui élimine au passage une classe d'attaques par tab-nabbing. COEP exige que chaque ressource embarquée consente explicitement à l'être. CORP est ce signal de consentement pour vos propres ressources.

Compromis assumé : COEP en mode require-corp cassera les images, iframes et widgets tiers qui n'envoient pas d'en-têtes CORP, et le débogage est fastidieux. Si vous manipulez des données de paiement, des données de santé, ou quoi que ce soit qui nécessite SharedArrayBuffer, faites le travail. Pour un site de contenu, COOP: same-origin seul est un point d'arrêt raisonnable.

Les en-têtes à supprimer en 2026

Les vieux extraits de configuration traînent du poids mort, et une partie est activement nuisible :

• X-XSS-Protection : l'auditeur qu'il pilotait a été retiré de tous les grands navigateurs il y a des années, et sur les anciens navigateurs, le filtre lui-même permettait des fuites d'information. Ne mettez rien, ou 0 si un scanner insiste.
• Expect-CT : obsolète. La Certificate Transparency est obligatoire dans les navigateurs depuis des années.
• X-Frame-Options : supplanté par frame-ancestors. Conservez-le uniquement si vous supportez réellement des clients préhistoriques, et vérifiez qu'il ne contredit pas votre CSP.
• X-Powered-By et les valeurs Server bavardes : ce ne sont pas des en-têtes de sécurité, mais supprimez-les quand même. De la reconnaissance gratuite pour les attaquants, zéro valeur pour vous.

Déployer une CSP sans casser la production

C'est la partie que tous les guides escamotent. Voici la séquence que nous déroulons sur les projets clients :

1. Commencez par inventorier la réalité. Déployez Content-Security-Policy-Report-Only avec votre politique stricte cible et un endpoint de rapport. Rien ne bloque encore, vous collectez simplement les violations du trafic réel, y compris les pixels marketing que personne n'a documentés.
2. Câblez le reporting proprement. Utilisez l'en-tête moderne Reporting-Endpoints et pointez report-to dessus. Hébergez le collecteur vous-même ou passez par un service, mais dans tous les cas, faites atterrir les rapports au même endroit que vos autres alertes.
3. Triez pendant deux à quatre semaines. Les vraies violations se regroupent vite : extensions de navigateur (du bruit, à ignorer), injections du gestionnaire de tags (à corriger par propagation de nonce), gestionnaires inline hérités du type onclick= (à refactorer, c'est en général le gros du travail).
4. Corrigez l'application, pas la politique. Chaque fois que vous êtes tenté d'élargir la politique, demandez-vous si ce n'est pas le code qui devrait changer. Un unsafe-inline ajouté "provisoirement" est définitif. Nous ne l'avons jamais vu retiré par la suite.
5. Passez en mode bloquant sur une route à faible risque d'abord. Basculez de Report-Only à l'application stricte sur vos pages marketing ou un outil interne. Surveillez les taux d'erreur et les rapports pendant une semaine.
6. Généralisez, en gardant Report-Only actif. Faites tourner les deux en-têtes côte à côte : la politique appliquée comme plancher, une candidate plus stricte en Report-Only comme prochaine itération. C'est ainsi que vous resserrez la vis dans le temps sans jouer à la roulette.
7. Ajoutez un test de régression. Une étape de CI qui interroge vos routes clés et vérifie les en-têtes s'écrit en une heure. Elle vous épargnera l'incident de 2 heures du matin où une migration de CDN a silencieusement fait disparaître tous les en-têtes que vous aviez déployés.

Cette dernière étape compte plus que n'importe quel en-tête pris isolément. D'expérience, les régressions d'en-têtes se produisent aux frontières d'infrastructure : un nouveau reverse proxy, un changement de CDN, une migration de plateforme. Personne ne remarque rien pendant des mois parce que rien ne casse visiblement. La vérification appartient au pipeline, pas à la mémoire de quelqu'un. C'est le même argument que nous défendons à propos de la sécurité des API : un contrôle que vous ne vérifiez pas en continu n'existe pas.

Où les définir, et comment vérifier

Définissez les en-têtes à la couche la plus externe que vous contrôlez, une seule fois. Des valeurs contradictoires émises par plusieurs couches provoquent des comportements navigateur franchement étranges, et avec la CSP, plusieurs en-têtes se combinent par intersection, ce qui signifie en général "le plus strict gagne" d'une manière que personne n'avait voulue.

Pour une périphérie nginx :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Le drapeau always est essentiel : sans lui, nginx supprime vos en-têtes sur les 404 et les 500, précisément les réponses que les attaquants sondent. La CSP à nonces ne peut pas vivre dans une configuration statique : générez-la par requête dans l'application ou dans un worker en périphérie.

Côté outillage de vérification, ce qui mérite sa place : Mozilla Observatory et securityheaders.com pour le regard extérieur, le CSP Evaluator de Google pour la qualité de la politique, et une boucle curl en CI pour les régressions. La course à la note a toutefois un mode d'échec bien connu : un A+ avec une CSP qui s'auto-neutralise vaut moins qu'un B avec une vraie politique, parce qu'il fabrique de la fausse confiance. Les scanners vérifient la présence, pas la justesse. C'est exactement l'angle mort qu'un test d'intrusion digne de ce nom est conçu pour exposer.

Un cadre de décision selon le type d'application

• Site vitrine statique : HSTS, nosniff, Referrer-Policy, Permissions-Policy, CSP basée sur des hachés avec frame-ancestors. Une demi-journée de travail, risque quasi nul.
• Tableau de bord SaaS : tout ce qui précède, plus une CSP stricte à nonces avec reporting, et COOP. Prévoyez trois à six semaines de temps calendaire pour le déploiement de la CSP, essentiellement passées à attendre les données Report-Only.
• Fintech, santé, tout secteur régulé : le jeu complet, y compris l'isolation COEP/CORP, un connect-src serré, et des assertions d'en-têtes en CI comme condition de mise en production. Les en-têtes deviennent des éléments de preuve pour votre conformité, du RGPD à DORA en passant par PCI DSS.
• Produit de widget embarqué : vous êtes de l'autre côté de la table. Servez des en-têtes CORP corrects, concevez pour les politiques CSP de vos clients, et documentez les directives exactes dont les intégrateurs ont besoin.

La règle transversale : chaque en-tête garde une frontière, et vous devez savoir laquelle. Si personne dans l'équipe ne sait expliquer pourquoi un en-tête est là, c'est soit du poids mort, soit une panne en sursis.

Comment Innovation T peut vous aider

Innovation T construit et durcit des plateformes web pour des clients en Europe et en Afrique du Nord : déploiements de CSP stricte sur des produits en exploitation, isolation cross-origin pour les applications sensibles, et pipelines CI qui traitent les en-têtes de sécurité comme du code testé. Nous avons fait le travail de tri Report-Only suffisamment de fois pour compresser des semaines de tâtonnements en un processus prévisible.

Si votre dernière revue d'en-têtes se résume à un extrait copié-collé, découvrez ce que couvrent nos services d'ingénierie et de sécurité ou parlez-nous d'un audit. La première passe prend en général quelques jours, pas des mois, et c'est la réduction de surface d'attaque la moins chère que vous achèterez cette année.