Security Headers Analyzer

Analyze HTTP response headers for security best practices

HTTP Response Headers

Paste raw response headers (from your server, curl -I, or browser devtools).

Analysis

HSTS
Header not present
Forces HTTPS and protects against protocol downgrade attacks.
CSP
Header not present
Mitigates XSS by whitelisting sources.
X-Frame-Options
Header not present
Prevents clickjacking in iframes.
X-Content-Type-Options
Header not present
Prevents MIME sniffing.
Referrer-Policy
Header not present
Controls referer leakage.
Permissions-Policy
Header not present
Restricts powerful browser features.
COOP
Header not present
Isolates browsing context for security.
COEP
Header not present
Required for certain isolation models.
CORP
Header not present
Restricts cross-origin resource loading.

Analyseur d'En-têtes de Sécurité - Vérifier les Headers HTTP

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.

En‑têtes essentiels et mécanismes de protection

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.

CSP : configuration avancée et bonnes pratiques

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.

Implémentation HSTS et gestion des sous‑domaines

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.

Pièges fréquents et dépannage

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.

En‑têtes pour APIs et SPAs

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.

Supervision, conformité et industrialisation

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.

Further reading

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.