Headers de sécurité : protégez efficacement votre site

Headers de sécurité, CSP, HSTS et politiques de navigation forment une première ligne de protection côté navigateur. Correctement configurés, ces en-têtes HTTP limitent les injections de scripts, le détournement d’interface et les connexions non sécurisées. Leur efficacité doit être vérifiée par un diagnostic technique adapté au fonctionnement réel du site.

Ce qu’il faut retenir

Headers de sécurité : définition et rôle réel

Lorsqu’un internaute consulte une page, son navigateur envoie une requête HTTP au serveur. Celui-ci retourne le document demandé avec des en-têtes de réponse. Ces informations précisent le type de contenu, les règles de cache, les redirections et les protections que le navigateur doit appliquer.

Les headers de sécurité agissent au niveau du navigateur. Ils complètent la protection du serveur, du CMS et du code applicatif. Ils ne corrigent pas une extension vulnérable et ne remplacent ni les mises à jour, ni l’authentification forte, ni les sauvegardes.

Leur objectif est de limiter les comportements autorisés lors du chargement d’une page. Ils rendent certaines attaques plus difficiles et réduisent l’impact potentiel d’une vulnérabilité présente sur le site.

Quels risques les headers de sécurité peuvent-ils limiter ?

Chaque header répond à un risque précis. Une politique cohérente limite les actions qu’une page, un script ou un domaine tiers peut imposer au navigateur de l’utilisateur.

• Injection de scripts : une politique CSP contrôle les sources depuis lesquelles les scripts, styles, images et polices peuvent être chargés.
• Clickjacking : la directive frame-ancestors de CSP, ou X-Frame-Options sur les anciens environnements, encadre l’affichage du site dans une iframe.
• Contournement de HTTPS : HSTS demande au navigateur d’utiliser uniquement une connexion chiffrée pendant une durée définie.
• Interprétation incorrecte d’un fichier : X-Content-Type-Options empêche le navigateur de deviner un type MIME différent de celui déclaré.
• Fuite d’informations : Referrer-Policy contrôle les informations transmises lorsqu’un utilisateur suit un lien vers une autre page.
• Accès aux fonctions du navigateur : Permissions-Policy encadre l’utilisation de la caméra, du microphone, de la géolocalisation ou d’autres fonctions sensibles.

Les principaux headers de sécurité à contrôler

La documentation MDN sur les en-têtes HTTP détaille leur syntaxe et leur compatibilité. Le choix des directives doit toutefois rester lié au fonctionnement réel du site.

Content Security Policy : le contrôle le plus structurant

Content-Security-Policy, souvent abrégé CSP, définit les sources autorisées pour chaque famille de ressources : scripts, styles, images, polices, vidéos et connexions externes.

Une CSP efficace repose sur une liste courte et justifiée. Les jokers, les domaines trop généraux et les directives permissives réduisent sa portée. À l’inverse, une politique trop stricte peut bloquer un paiement, un formulaire, une vidéo ou une mesure d’audience.

Le mode Content-Security-Policy-Report-Only permet d’observer les violations sans bloquer immédiatement les ressources. Les règles sont ensuite corrigées avant l’activation définitive de la politique.

Pour approfondir ce réglage, consultez le guide Eur’Net consacré à CSP et HSTS.

HSTS : imposer HTTPS avec précaution

Strict-Transport-Security indique au navigateur qu’un domaine doit être contacté uniquement en HTTPS pendant la durée définie par la valeur max-age. Cette règle protège les visites suivantes contre certaines tentatives de retour vers une connexion non chiffrée.

Avant d’ajouter includeSubDomains, tous les sous-domaines doivent fonctionner durablement en HTTPS. Un ancien service, une application métier ou une interface technique encore accessible en HTTP pourrait devenir indisponible.

L’option preload exige davantage de prudence, car son retrait n’est pas immédiat. Les certificats, les redirections, les sous-domaines et les contenus mixtes doivent être vérifiés avant son activation.

Headers de sécurité, performance et SEO

Les headers de sécurité ne constituent pas, à eux seuls, un facteur direct de positionnement. Ils favorisent néanmoins un environnement fiable, une navigation en HTTPS et une meilleure maîtrise des ressources chargées.

Les règles de cache, comme Cache-Control, répondent à un autre objectif. Elles peuvent améliorer les temps de chargement lorsqu’elles sont adaptées à la nature et à la fréquence de mise à jour des contenus.

Il faut donc distinguer les headers de sécurité, la gestion du cache et les directives d’indexation. Une configuration cohérente soutient la qualité technique du site sans présenter chaque en-tête HTTP comme un levier SEO direct.

Comment réaliser un diagnostic des headers de sécurité ?

Un diagnostic des headers de sécurité ne se limite pas à la page d’accueil. Les réponses HTTP peuvent varier selon le serveur, le CDN, le CMS, les sous-domaines, les types de fichiers et les règles appliquées aux pages sensibles.

Les pages de connexion, les formulaires, les espaces clients et les parcours de paiement nécessitent une attention particulière. Ils utilisent souvent des scripts ou des services externes qui doivent être pris en compte dans la politique de sécurité.

1. Inventorier les domaines, sous-domaines et services externes utilisés.
2. Relever les headers de sécurité reçus sur plusieurs pages.
3. Contrôler également les redirections et les réponses d’erreur.
4. Comparer les valeurs avec les fonctions réellement nécessaires.
5. Identifier les directives absentes, contradictoires ou permissives.
6. Tester les corrections sur un environnement de préproduction.
7. Déployer progressivement puis surveiller les erreurs applicatives.

Une analyse automatisée fournit un premier état, mais elle ne connaît pas le contexte métier. Le diagnostic doit expliquer les conséquences de chaque réglage et proposer une correction compatible avec l’architecture du site.

Eur’Net présente cette démarche dans son service de diagnostic cyber non intrusif.

Erreurs fréquentes dans les headers de sécurité

• Activer HSTS avec includeSubDomains sans vérifier tous les services.
• Déployer CSP directement en blocage sans phase d’observation.
• Autoriser trop de domaines externes pour faire disparaître les alertes.
• Utiliser des jokers qui réduisent fortement l’efficacité de CSP.
• Conserver des headers historiques devenus inutiles ou contradictoires.
• Appliquer une configuration identique à des sites aux besoins différents.
• Tester uniquement la page d’accueil et oublier les réponses d’erreur.
• Considérer la présence d’un header comme une preuve suffisante de sécurité.

Questions fréquentes sur les headers de sécurité

Quels headers de sécurité faut-il installer en priorité ?

CSP, HSTS, X-Content-Type-Options, Referrer-Policy et Permissions-Policy constituent une base fréquente. La configuration dépend cependant des services utilisés, des sous-domaines et des contenus externes. L’objectif n’est pas d’accumuler des headers, mais d’appliquer des règles cohérentes et vérifiables.

Les headers de sécurité empêchent-ils toutes les attaques ?

Non. Les headers de sécurité réduisent certains risques côté navigateur et peuvent limiter l’exploitation d’une faille. Ils ne remplacent pas les mises à jour, la correction du code, la protection des comptes, la supervision, les sauvegardes et la sécurisation du serveur.

Peut-on copier une configuration trouvée en ligne ?

Une configuration générique peut servir de point de départ, mais elle doit être adaptée. Les scripts, les polices, les outils de mesure, les formulaires et les services de paiement diffèrent selon les sites. Une règle copiée peut rester inefficace ou interrompre une fonction légitime.

Comment vérifier que les headers de sécurité sont efficaces ?

Il faut contrôler leur présence, leur valeur et leur application sur plusieurs réponses HTTP. Les tests doivent couvrir les pages sensibles, les sous-domaines et les erreurs. Une nouvelle vérification après chaque évolution importante permet de détecter les régressions.

À quelle fréquence faut-il réaliser un diagnostic ?

Une vérification est recommandée après une modification du serveur, du CDN, du CMS ou des services externes. Un contrôle périodique permet également d’identifier les protections supprimées ou modifiées lors d’une mise à jour technique.

Renforcer les headers de sécurité de votre site

Une bonne configuration commence par un diagnostic du site, de ses dépendances et de son infrastructure. Les corrections sont ensuite classées par risque, testées et documentées.

Consultez le dossier Eur’Net sur les security headers d’un site web ou demandez un diagnostic technique pour vérifier les protections actuellement appliquées.

Vous souhaitez contrôler les headers de sécurité de votre site ?

Réservez votre diagnostic avec l’équipe Eur’Net.