Security Headers Analyzer
Analyze HTTP response headers for security best practices
Analyze HTTP response headers for security best practices
Les en‑têtes de sécurité HTTP constituent une première ligne de défense contre les vulnérabilités Web : ils ordonnent aux navigateurs d’appliquer des politiques protégeant des attaques XSS, du clickjacking, des MITM et des fuites de données. Cet analyseur évalue les en‑têtes de réponse de votre site selon les bonnes pratiques, identifie les protections manquantes et fournit des recommandations concrètes pour durcir votre application. Une configuration correcte est essentielle pour la conformité, la confiance et la défense face aux menaces émergentes.
Content‑Security‑Policy (CSP) réduit le XSS en contrôlant les sources et les scripts inline. Strict‑Transport‑Security (HSTS) impose HTTPS et empêche les attaques de rétrogradation. X‑Frame‑Options et frame‑ancestors préviennent le clickjacking en maîtrisant l’intégration iframe. X‑Content‑Type‑Options bloque le MIME sniffing. Referrer‑Policy limite les fuites d’informations. Permissions‑Policy restreint l’accès aux API du navigateur (caméra, micro, géolocalisation). Ensemble, ils assurent une défense en profondeur.
La CSP doit concilier sécurité et fonctionnalité. Démarrez avec une politique restrictive (par ex. default‑src 'self'; img‑src 'self' data:; style‑src 'self' 'unsafe‑inline'; script‑src 'self') et relâchez si nécessaire. Utilisez des nonces ou des hachages plutôt que 'unsafe‑inline'. Déployez progressivement : d’abord en mode report‑only, corrigez, puis appliquez. Surveillez les rapports pour détecter attaques et erreurs de configuration. Pour les apps complexes, adoptez des politiques différenciées ou strict‑dynamic.
HSTS empêche le SSL stripping en forçant l’usage de HTTPS lors des connexions futures. Commencez par un max‑age court pour les tests, puis augmentez en production. 'includeSubDomains' protège tous les sous‑domaines – assurez‑vous qu’ils supportent HTTPS. Envisagez 'preload' pour la protection dès la première visite. HSTS est persistant : les navigateurs mémorisent la politique même après retrait, d’où la nécessité de tests approfondis.
Une CSP trop permissive (script‑src '*' ou 'unsafe‑eval') annule les bénéfices. L’absence de HSTS sur les pages de connexion expose aux attaques de rétrogradation. Une configuration X‑Frame‑Options incorrecte peut casser des iframes légitimes ou ne pas empêcher le clickjacking. Des en‑têtes en conflit (X‑Frame‑Options vs frame‑ancestors) provoquent des comportements inattendus. Testez dans plusieurs navigateurs et parcours ; utilisez les outils pour repérer les violations CSP, valider HSTS et vérifier la présence des en‑têtes sur les pages sensibles.
Les APIs requièrent une configuration différente : CORS régit l’accès cross‑origin, et la CSP est moins pertinente pour les endpoints JSON. Les SPAs nécessitent une CSP soignée pour autoriser le chargement dynamique tout en évitant le XSS. Envisagez COEP/COOP pour une meilleure isolation. Les gateways et CDNs doivent préserver les en‑têtes de sécurité de l’origine. Appliquez‑les de façon cohérente en dev/staging/prod pour détecter tôt les problèmes.
Supervisez avec des outils (Security Headers, Mozilla Observatory) ou des scans CI/CD. Journalisez les violations CSP et les rapports HSTS pour détecter attaques et erreurs. À grande échelle, utilisez la gestion de configuration et des politiques 'as code' pour la cohérence. Réalisez des audits réguliers, vérifiez l’efficacité et surveillez les nouveaux standards. Les cadres de conformité (p. ex., SOC 2, PCI DSS) exigent souvent ces en‑têtes.
Security headers provide essential protection against web vulnerabilities with minimal performance impact. Implement progressively, monitor violations, test thoroughly across browsers and user flows, and maintain policies as your application evolves. Regular security header audits should be part of your security maintenance routine.