Un vérificateur d'en-têtes HTTP affiche les métadonnées renvoyées par un serveur pour une URL. Screpy effectue une requête GET publique, suit les redirections prises en charge et liste les noms et valeurs des en-têtes de la réponse finale sans télécharger le corps de la page. Utilisez le rapport pour examiner une redirection, vérifier une modification d'en-tête après publication ou repérer une directive d'indexation inattendue.
Commencez par la réponse reçue, puis comparez-la au comportement attendu de la ressource. Une vérification terminée peut révéler une erreur serveur ou une politique inadaptée. Un résultat vert ne certifie ni la sécurité, ni les performances du cache, ni l'indexation.
Vérifier l'URL exacte et sa chaîne de réponses
Saisissez une adresse publique HTTP ou HTTPS complète, avec le chemin et les paramètres utiles. La page d'accueil, un PDF et une fiche produit peuvent renvoyer des en-têtes différents sur le même domaine. Pour une fiche produit fictive, https://example.com/products/blue-mug/ est plus pertinent que la racine si c'est cette réponse que vous voulez examiner.
Lisez la chaîne avant le tableau. Une redirection peut changer le protocole, l'hôte ou le chemin. Le tableau contient les en-têtes de la réponse finale, et non tous les en-têtes de chaque étape. La chaîne comprend aussi la réponse finale : son nombre d'étapes n'est donc pas nécessairement celui des redirections.
Vérifiez que l'URL finale correspond à la ressource visée. Une page de connexion, d'erreur ou un autre hôte peut expliquer des valeurs inattendues. Utilisez Redirect Checker pour examiner surtout le parcours de redirection plutôt que la liste finale des en-têtes.
Lire un exemple de réponse HTTP
Cette réponse fictive montre que chaque champ répond à une question différente. Ce n'est ni un résultat capturé ni une configuration à copier sur toutes les pages.
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Robots-Tag: noindex
Le statut 200 indique une réponse réussie. Content-Type déclare du HTML encodé en UTF-8. Cache-Control décrit les instructions de cache, tandis que X-Robots-Tag fournit une instruction d'indexation. Une réponse fonctionnelle peut donc contenir noindex : un succès HTTP ne signifie pas que la page est destinée aux résultats de recherche.
Le tableau normalise les noms en minuscules ; leur casse ne crée pas des champs distincts. La référence MDN sur les en-têtes distingue les champs de requête et de réponse. Ce vérificateur affiche la réponse, pas les cookies, préférences ou informations d'authentification de votre session de navigation.
Examiner séparément le cache et l'indexation
Filtrez le tableau par nom d'en-tête pour examiner un problème précis. Définissez d'abord les besoins de la ressource : du HTML souvent modifié, un fichier versionné et un document volontairement exclu de la recherche ne demandent pas forcément la même politique.
| En-tête | Question utile lors de l'examen |
|---|---|
content-type |
Le format déclaré correspond-il à la ressource attendue ou une redirection a-t-elle abouti à une autre réponse ? |
cache-control |
La politique convient-elle aux exigences de mise à jour et de confidentialité de cette ressource ? |
etag ou last-modified |
Un validateur est-il présent pour les requêtes conditionnelles ? Sa présence ne teste pas la revalidation. |
vary |
Quelles différences d'en-têtes de requête la réponse identifie-t-elle pour la sélection du cache ? |
x-robots-tag |
La directive noindex observée est-elle voulue pour cette URL ? |
no-cache ne signifie pas « ne jamais stocker ». Il autorise le stockage, mais exige une validation avant réutilisation. no-store demande aux caches de ne pas conserver la réponse. La référence MDN sur Cache-Control explique cette différence. Le contrôle ne mesure pas les réponses servies depuis le cache et ne supprime pas les copies déjà stockées.
Une directive d'indexation est une décision distincte de la fraîcheur du contenu. Si une page prévue pour l'indexation renvoie noindex de façon inattendue, trouvez l'application, le réglage serveur ou la règle responsable avant de la modifier. Utilisez Noindex Checker pour examiner aussi les directives HTML. La documentation noindex de Google décrit l'instruction ; l'observer ne prouve pas l'état actuel de l'index Google.
Comprendre les observations sur les en-têtes de sécurité
Screpy signale certaines déclarations à examiner. Traitez un constat comme une question de configuration, pas comme un rapport de vulnérabilité ni comme une invitation à copier une politique inconnue en production.
| Observation | Ce que la vérification établit et ce qu'elle n'établit pas |
|---|---|
| Examen HSTS | Recherche un max-age positif dans une réponse HTTPS. Ne valide ni tout le déploiement HTTPS ni les certificats. |
| CSP absente | Recherche Content-Security-Policy dans une réponse déclarée HTML. Sa présence ne garantit pas que ses directives protègent l'application. |
| Examen de l'intégration dans un cadre | Recherche frame-ancestors dans CSP ou une valeur reconnue de X-Frame-Options. Autoriser l'intégration dépend du rôle de la page. |
| Examen de la détection MIME | Vérifie si X-Content-Type-Options déclare nosniff. Ne vérifie ni le contenu réel du fichier ni le comportement de chaque navigateur. |
Un constat informatif ou l'absence d'une politique ne prouve pas une faille. De même, un en-tête présent ne rend pas une politique efficace. La documentation CSP de MDN distingue les politiques appliquées de Content-Security-Policy-Report-Only, qui signale les violations sans imposer ces restrictions. Ce dernier ne prouve pas qu'une politique contraignante est présente.
Examinez les modifications selon les ressources et besoins d'intégration réels de l'application. Le vérificateur n'attribue pas de note de sécurité, n'inspecte pas les certificats et ne valide pas toutes les directives. Pour les références à des ressources non sécurisées dans le HTML, utilisez séparément Mixed Content Checker.
Interpréter les valeurs répétées et masquées
Le nombre d'en-têtes correspond aux noms normalisés distincts. La colonne d'occurrences indique le nombre d'apparitions d'un nom, et les valeurs ordinaires répétées restent visibles. Plusieurs occurrences ne constituent pas automatiquement une erreur : vérifiez si le champ autorise cette structure et si la politique combinée est voulue.
Les valeurs sensibles de cookies, d'authentification et les secrets reconnus sont masqués ou nettoyés. Une valeur masquée n'est pas un en-tête absent, et sa présence n'est pas une évaluation de la sécurité des cookies. Ne réintroduisez pas ces valeurs dans un rapport partagé. Examinez les détails confidentiels uniquement dans un environnement privé de diagnostic adapté.
Filtrez sur le nom, par exemple cache-control, sans attendre une recherche dans toutes les valeurs. Conservez le rapport avec l'URL et l'heure du contrôle pour vos comparaisons. Interprétez un champ présent ou absent avec le statut final, le type de ressource et l'avis de couverture.
Distinguer les contrôles partiels des erreurs HTTP
Une réponse d'erreur du serveur est différente d'un serveur inaccessible. Lisez l'avis de couverture avant d'interpréter les lignes absentes.
| Résultat | Signification et prochaine action |
|---|---|
404 ou 500 final avec en-têtes |
Une réponse a été observée. Confirmez l'URL et examinez l'erreur de ressource ou de serveur ; une connexion réussie n'est pas une page réussie. |
| Chaîne partielle | Certaines étapes ont été observées, sans pouvoir vérifier la réponse finale. Ses en-têtes sont indisponibles, pas confirmés absents. |
| Délai dépassé ou source indisponible | La réponse demandée n'a pas été obtenue. Vérifiez accès public, adresse et redirections avant de recommencer. |
Le vérificateur suit un nombre borné de redirections et attend pendant une durée limitée. Les boucles, destinations inaccessibles ou réponses dépassant les limites peuvent laisser le contrôle incomplet. Une liste finale vide n'est alors pas une liste d'en-têtes de sécurité manquants.
Les adresses de réseau privé, pages authentifiées et requêtes nécessitant vos cookies sont hors du champ du formulaire. Une restriction d'accès ne prouve pas non plus ce que reçoit Googlebot ou un autre visiteur réel.
Comparer les en-têtes après publication
Avant une modification, notez l'URL exacte, la réponse finale, l'heure et le champ qui devrait changer. Exportez le rapport comme état de référence. Après publication de la configuration voulue, contrôlez la même URL et comparez les valeurs pertinentes, pas seulement le nombre d'en-têtes ou d'alertes. Répétez sur un autre type de ressource si la règle doit aussi s'y appliquer.
Si le navigateur montre autre chose, ouvrez son panneau Réseau, rechargez la page et examinez la requête concernée. Comparez l'URL après redirections, la méthode et l'état de connexion. Une réponse en cache ou personnalisée peut différer d'une requête publique depuis un autre emplacement. Le formulaire n'envoie pas vos cookies et ne permet pas d'ajouter vos propres en-têtes d'authentification.
Vérifiez aussi si un autre outil emploie HEAD plutôt que GET. La RFC 9110 explique que HEAD ne contient pas de corps et peut omettre certains champs calculés pendant la génération du contenu. Screpy utilise GET, mais s'arrête avant de télécharger le corps. Des méthodes et conditions comparables aident à examiner une différence ; elles ne rendent pas toutes les réponses identiques.