01À quoi servent les en-têtes de sécurité ?
À chaque réponse, un site peut envoyer des en-têtes de sécurité qui donnent des consignes au navigateur : n'exécuter que les scripts autorisés (CSP), refuser le HTTP non chiffré (HSTS), interdire la mise en iframe (anti-clickjacking)… Ce sont des protections gratuites, appliquées par tous les navigateurs modernes, qui neutralisent des classes entières d'attaques — XSS, interception, détournement de clic.
Cet outil lit les en-têtes renvoyés par l'URL (après ses redirections, tracées comme dans notre traceur) et note la configuration de A+ à F. Pour voir les en-têtes que votre navigateur envoie, c'est notre outil en-têtes HTTP.
02Les six protections vérifiées
- CSP
- Content-Security-Policy : liste blanche des sources de scripts, styles, images… La défense la plus puissante contre les XSS, et la plus exigeante à configurer.
- HSTS
- Strict-Transport-Security : impose HTTPS au navigateur pendant max-age secondes. Contre le SSL stripping ; 6 mois minimum recommandé.
- nosniff
- X-Content-Type-Options: nosniff : interdit au navigateur de deviner le type d'un fichier, empêchant d'exécuter un faux « image.jpg » contenant du script.
- Clickjacking
- X-Frame-Options ou CSP frame-ancestors : contrôle qui peut charger le site en iframe, contre le détournement de clics.
- Referrer
- Referrer-Policy : limite ce que l'URL de provenance révèle aux sites tiers (paramètres, chemins internes).
- Permissions
- Permissions-Policy : coupe l'accès caméra / micro / géolocalisation aux iframes tierces (publicités incluses).
03En ligne de commande
La même URL que cette page répond en texte brut, et l'API JSON renvoie chaque vérification structurée (CORS ouvert) — intégrable dans une CI pour surveiller vos déploiements :
$ curl "its-my-ip.com/security?url=https://exemple.fr" grade: B content-security-policy: missing strict-transport-security: ok max-age=31536000 $ curl "its-my-ip.com/api/security?url=https://exemple.fr" { "grade": "B", "checks": { "csp": { "status": "err" }, … } }
04Questions fréquentes
Quelle note viser pour mon site ?
A ou A+ pour tout site avec des comptes utilisateurs ou des paiements. Un site vitrine statique peut vivre avec un B, mais les en-têtes manquants (nosniff, Referrer-Policy, X-Frame-Options) se posent en cinq minutes — il n'y a guère de raison de s'en priver. Seule la CSP demande un vrai travail d'inventaire des sources.
Où configurer ces en-têtes ?
Au niveau du serveur web (nginx : add_header, Apache : Header set), du framework (helmet pour Node.js, SecurityMiddleware pour Django), ou du CDN (Cloudflare Transform Rules, règles _headers chez Netlify/Vercel). Un seul endroit suffit : évitez de les déclarer en double, des valeurs contradictoires créent des bugs subtils.
Pourquoi ma CSP est-elle marquée « à améliorer » ?
Parce qu'elle contient unsafe-inline ou unsafe-eval sans nonce ni hash : n'importe quel script injecté dans la page peut alors s'exécuter, ce qui vide la CSP de son intérêt principal. La solution moderne est un nonce aléatoire par réponse (script-src 'nonce-…') ou les hash sha256 des scripts inline légitimes.
Activer HSTS peut-il casser mon site ?
Oui, si un sous-domaine n'est pas servi en HTTPS et que vous utilisez includeSubDomains : le navigateur refusera de s'y connecter jusqu'à expiration du max-age. Commencez avec un max-age court (300), vérifiez tous vos sous-domaines, puis augmentez progressivement vers 6 mois ou 1 an. Le retrait est long : les navigateurs mémorisent la directive.
Ces en-têtes suffisent-ils à sécuriser un site ?
Non — ils sont une couche de défense en profondeur côté navigateur. Ils ne corrigent ni une injection SQL, ni une authentification défaillante, ni une dépendance vulnérable. Mais ils transforment beaucoup de failles exploitables en failles inertes, pour un coût quasi nul : c'est le meilleur ratio effort/protection du web.