Aller au contenu
ipaddress.fi

Vérification des en-têtes de sécurité

Nous récupérons les en-têtes de réponse d’une URL publique (sans le contenu) et vérifions un à un les en-têtes protecteurs.

Exemples:

Certaines des protections les plus efficaces du web sont de simples en-têtes de réponse HTTP, définis une fois sur le serveur. La vérification récupère les en-têtes de réponse d’une URL publique, suit les redirections jusqu’à la page finale et les évalue un par un :

  • Strict-Transport-Security oblige les navigateurs à n’utiliser que HTTPS.
  • Content-Security-Policy limite l’origine des scripts et autres ressources et, avec frame-ancestors, qui peut intégrer la page.
  • X-Content-Type-Options: nosniff empêche les navigateurs de deviner les types de fichiers.
  • Referrer-Policy contrôle la part de l’URL transmise aux autres sites.
  • Permissions-Policy désactive les fonctions du navigateur inutilisées par le site.
  • Cross-Origin-Opener-Policy isole la page des fenêtres qu’elle ouvre.

Les versions logicielles exposées dans Server ou X-Powered-By sont également signalées. Le résultat est une liste de contrôle, pas une note de sécurité : les en-têtes ne sont qu’une couche de protection parmi d’autres.

Questions fréquentes

Pourquoi un HSTS de moins de six mois est-il jugé faible ?

Les navigateurs ne retiennent l'obligation HTTPS que pendant max-age secondes. Six mois à un an est la recommandation habituelle et un prérequis pour les listes de préchargement des navigateurs.

X-Frame-Options est-il encore nécessaire ?

La directive CSP frame-ancestors le remplace dans les navigateurs modernes. Ici, l'un ou l'autre compte comme protection contre l'intégration.

L'outil envoie-t-il autre chose qu'une requête normale ?

Non. Il envoie une requête GET ordinaire par étape de redirection, ne lit que les en-têtes et ferme la connexion.

Voir aussi