urldiagnostics.com

Gratuit · Analyse côté serveur

Vérificateur d’en-têtes de sécurité

Collez une URL. Nous récupérons ses en-têtes de réponse en toute sécurité, notons les en-têtes de sécurité les plus significatifs avec un score transparent, et vous fournissons des corrections prudentes et prêtes à copier pour votre stack.

En bref

  • Notez HSTS, CSP, la protection contre le clickjacking, Referrer-Policy, Permissions-Policy et X-Content-Type-Options.
  • Comprenez précisément pourquoi chaque en-tête réussit, est faible ou est manquant — et son impact en langage clair.
  • Copiez une base de durcissement pour Nginx, Apache, Express/Next.js, Cloudflare Workers ou Netlify/Vercel.

🔒 Analyse côté serveur : vos en-têtes de réponse publics sont récupérés en mémoire. Les destinations privées, locales et réservées sont bloquées, les réponses et redirections sont plafonnées, et les URL soumises ne sont pas conservées.

Ce que cela signifie

Les en-têtes sont des garde-fous, pas un audit complet

Les en-têtes de sécurité HTTP indiquent au navigateur comment défendre votre page — forcer le HTTPS, bloquer les scripts injectés, empêcher le clickjacking et limiter les données divulguées à d’autres sites. Ils constituent une base rapide et à fort signal, mais ne remplacent pas une revue de sécurité complète.

Comment la note est-elle calculée ?

Le score est déterministe et visible : CSP vaut 25 points, HSTS 20, la protection contre le clickjacking 15, Referrer-Policy 15, Permissions-Policy 15 et X-Content-Type-Options 10 — soit 100 au total. Un en-tête présent et robuste obtient tous les points, un en-tête faible la moitié, et un en-tête manquant zéro. Les notes en lettres sont A+ (95+), A (85+), B (70+), C (55+), D (40+), et F sinon.

Pourquoi les suggestions CSP sont-elles si prudentes ?

Une mauvaise Content-Security-Policy peut casser un site sans prévenir, et une politique trop large n’offre aucune protection. Nous suggérons une politique de départ stricte et vous conseillons de la déployer d’abord en Content-Security-Policy-Report-Only, afin que vous puissiez élargir les sources jusqu’à ce que rien de légitime ne soit bloqué avant de l’appliquer.

Qu’en est-il de includeSubDomains et preload pour HSTS ?

Ils sont puissants mais risqués : includeSubDomains force le HTTPS sur tous les sous-domaines, et preload inscrit votre domaine dans les navigateurs de façon très difficile à annuler. La base définit uniquement un max-age d’un an et vous invite à ajouter ces indicateurs manuellement, après avoir confirmé que chaque sous-domaine sert bien du HTTPS.

Les URL vérifiées sont-elles conservées ?

Non. Le serveur récupère vos en-têtes de réponse publics en mémoire car les règles CORS du navigateur bloquent généralement les vérifications directes. Les requêtes passent par des protections contre les réseaux privés, ainsi que des protections DNS, de délai, de redirection et de taille de réponse, et rien de ce que vous soumettez n’est enregistré.