Vérificateur d’en-têtes HTTP
Sécurité, compression et cache
Ce vérificateur d’en-têtes HTTP lit la réponse de n’importe quelle page et la note en un seul passage : les huit en-têtes de sécurité, la compression, le cache et ce que le serveur révèle. Ensuite, il écrit les lignes qui corrigent chaque manque, pour Apache, Nginx ou un fichier d’en-têtes.
- GratuitPrix
- 23Contrôles
- InclusCorrectif
- RienConservé
Vérificateur d’en-têtes HTTP
Huit en-têtes de sécurité, la compression et le cache, jugés en un seul passage
- Score
- —
- Réussis
- 0
- Avertissements
- 0
- Échecs
- 0
- Premier octet
- —
| En-tête | Valeur | Verdict | Ce que cela veut dire |
|---|---|---|---|
| Collez une adresse ci-dessus et la réponse arrive ici. | |||
Le score est notre propre pondération des lignes ci-dessus, pas une note du secteur. HTTPS, la politique et la compression pèsent le plus ; ce qui est marqué comme information ne pèse rien.
Des lignes prêtes pour chaque en-tête ci-dessus en échec ou en alerte. Choisissez votre serveur, collez les lignes, puis relancez la vérification.
Prêt. Collez une adresse publique et ce serveur ouvre deux connexions vers elle.
Ce que décident les en-têtes de réponse
Chaque page arrive avec quelques lignes que le visiteur ne voit jamais. Ces lignes sont les en-têtes de réponse.
Elles disent au navigateur comment traiter la page : quels scripts peuvent s’exécuter, si elle peut être intégrée dans un cadre, combien de temps la garder et si elle est arrivée compressée.
Ainsi, deux pages au contenu identique peuvent être très différentes en vitesse et en sécurité. La différence tient entièrement aux en-têtes.
Ce vérificateur les lit depuis une adresse en ligne, note chacun, puis vous donne la configuration qui corrigerait les points faibles.
Les huit en-têtes de protection
Strict-Transport-Security maintient les navigateurs en HTTPS. Content-Security-Policy décide quels scripts peuvent s’exécuter, ce qui est la principale défense contre le code injecté.
X-Content-Type-Options oblige le navigateur à respecter le type de fichier déclaré, sans supposition. La protection contre l’intégration, via X-Frame-Options ou frame-ancestors, empêche d’autres sites d’encadrer le vôtre pour voler des clics.
Referrer-Policy limite ce que votre adresse révèle aux autres sites. De plus, Permissions-Policy coupe la caméra, le micro et la localisation sauf si une page les demande.
Enfin, les deux politiques cross-origin empêchent d’autres fenêtres et d’autres sites d’accéder à la page. Ensemble, ces huit en-têtes ferment la plupart des portes qu’un attaquant essaie d’abord.
Pourquoi la compression est vérifiée à part
Un serveur ne compresse que si le navigateur le demande. C’est pourquoi cet outil ouvre une seconde connexion qui propose gzip et brotli, puis indique ce qui revient.
La compression réduit en général une page HTML d’environ soixante-dix pour cent. Par conséquent, c’est l’un des gains de vitesse les moins chers, et l’un des plus souvent absents.
L’en-tête Vary est vérifié avec elle, car une page compressée sans Vary: Accept-Encoding peut être servie au mauvais navigateur par un cache partagé.
Le cache en termes simples
Cache-Control indique combien de temps une copie peut être réutilisée. Sans lui, chaque navigateur et chaque proxy invente sa règle, et ils s’accordent rarement.
ETag et Last-Modified permettent à un navigateur qui revient de demander si sa copie est encore à jour. Ainsi, il peut recevoir une toute petite réponse "non modifié" au lieu de la page entière.
Ce que révèle le serveur
Les en-têtes Server et X-Powered-By donnent souvent le logiciel et la version exacts. Cela n’aide aucun visiteur, pourtant cela épargne une étape à un attaquant.
Les cookies sont vérifiés aussi. Chacun devrait porter Secure, HttpOnly et SameSite, sinon il peut voyager en clair ou être lu par un script.
Comment le correctif est écrit
Pour chaque ligne en échec qu’une ligne de configuration peut corriger, l’outil écrit cette ligne. Vous choisissez Apache, Nginx ou un fichier _headers, et le bloc s’adapte.
La ligne Content-Security-Policy est écrite en Report-Only exprès. Une politique générique activée d’un coup peut bloquer les propres scripts d’un site, alors que le mode rapport montre d’abord ce qui casserait.
Certaines choses ne sont pas des problèmes d’en-têtes, comme un premier octet lent. Elles sont donc listées, mais laissées hors du bloc, afin que rien n’y prétende corriger ce qu’il ne peut pas.
À propos du score
Le score est notre propre pondération, pas une norme du secteur. HTTPS, la politique de contenu et la compression pèsent le plus, tandis que les lignes d’information ne pèsent rien.
Sur cette page
- L’outil
- Ce que décident les en-têtes de réponse
- Le vérificateur d’en-têtes HTTP, étape par étape
- Ce qui distingue ce vérificateur d’en-têtes
- Règles pour régler les en-têtes de réponse
- Six erreurs d’en-têtes qui restent cachées
- Les questions fréquentes sur les en-têtes HTTP
- Outils pour vérifier un serveur
Continuer
Le vérificateur d’en-têtes HTTP, étape par étape
Une adresse en entrée ; une réponse notée et un correctif prêt en sortie.
- 1
Indiquez l’URL à examiner
Toute page publique convient, et les redirections sont suivies jusqu’à la réponse finale.
- 2
Lisez la note, puis le détail
Les échecs passent d’abord dans chaque groupe. Chaque ligne dit ce qu’elle a trouvé et pourquoi c’est important.
- 3
Choisissez votre serveur
Choisissez Apache, Nginx ou un fichier _headers, et le bloc de correctif se réécrit pour ce serveur.
- 4
Collez, rechargez, revérifiez
Ajoutez les lignes, rechargez le serveur, puis relancez la vérification pour voir les lignes passer au vert.
Ce qui distingue ce vérificateur d’en-têtes
La plupart des outils affichent la liste brute et s’arrêtent. Celui-ci, au contraire, l’explique et la corrige.
Sécurité, vitesse et cache réunis
Vingt-trois contrôles en cinq groupes, au lieu de trois outils séparés qui ne voient chacun qu’une partie.
Le correctif, écrit pour vous
Des lignes prêtes pour Apache, Nginx ou un fichier _headers, seulement pour les lignes qui en ont besoin.
La compression vraiment testée
Une seconde connexion demande gzip et brotli, donc la réponse reflète ce que reçoit un vrai navigateur.
Une configuration prudente d’office
La politique de contenu arrive d’abord en mode rapport, donc essayer le correctif ne peut pas casser le site.
Les en-têtes bruts à portée de main
La liste non modifiée a son propre onglet pour qui veut lire chaque ligne.
Rien n’est conservé
L’adresse sert à une vérification puis disparaît. De plus, ce serveur n’en écrit aucune trace.
Règles pour régler les en-têtes de réponse
Huit habitudes qui gardent les en-têtes justes après le premier correctif.
- Réglez HTTPS avant tout. Chaque en-tête de sécurité suppose une connexion chiffrée. En HTTP en clair, la plupart ne font rien.
- Déployez la politique de contenu doucement. Commencez en mode rapport, lisez ce qu’elle bloquerait, puis activez-la une fois les rapports calmes.
- Augmentez HSTS par étapes. Commencez par un max-age court, vérifiez que chaque sous-domaine sert HTTPS, puis passez à une année entière.
- Compressez le texte, pas les images. HTML, CSS, JavaScript et SVG se réduisent beaucoup. En revanche, JPEG et WebP sont déjà compressés, donc gzip n’y gagne rien.
- Dites quelque chose sur le cache. Même no-store vaut mieux que le silence, car le silence laisse chaque cache deviner différemment.
- Masquez les numéros de version. Désactivez les server tokens et X-Powered-By. Ils n’aident que les attaquants.
- Marquez chaque cookie. Secure, HttpOnly et SameSite sur chacun, y compris les cookies posés par des extensions.
- Revérifiez après chaque déploiement. Un nouveau serveur, un CDN ou une extension peuvent supprimer des en-têtes en silence, donc relancez la vérification à chaque changement.
Six erreurs d’en-têtes qui restent cachées
Aucune ne se voit sur la page, et c’est justement pour cela qu’elles durent des années.
Une politique avec unsafe-inline
Elle ressemble à une politique de contenu, pourtant elle laisse s’exécuter le script injecté. Préférez un nonce ou une empreinte.
HSTS sur HTTP en clair
Les navigateurs l’ignorent alors. Il ne compte que lorsqu’il arrive sur une réponse HTTPS.
Des en-têtes seulement sur l’accueil
Les en-têtes de sécurité posés dans un seul modèle manquent sur toutes les autres pages. Définissez-les donc au niveau du serveur.
La compression coupée par un proxy
Un CDN ou un pare-feu devant le site peut défaire ce que l’origine a réglé. Vérifiez donc l’adresse que les visiteurs utilisent.
Des en-têtes en double
Deux valeurs différentes pour le même en-tête, l’une de l’application et l’autre du serveur, laissent le navigateur choisir.
Feature-Policy au lieu de Permissions-Policy
L’ancien nom a été retiré il y a des années. Les navigateurs actuels ne lisent que le nouveau.
Les questions fréquentes sur les en-têtes HTTP
Que contiennent les en-têtes HTTP d’une réponse ?
Ce sont de courtes lignes envoyées avec chaque réponse, avant la page elle-même. Elles indiquent au navigateur comment traiter la suite.
Quels en-têtes de sécurité ne devraient manquer sur aucun site ?
Au strict minimum : Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, un blocage des iframes, Referrer-Policy et Permissions-Policy. De plus, les deux politiques cross-origin ajoutent une protection.
Google récompense-t-il les en-têtes de sécurité ?
Pas directement. Cependant, HTTPS est un signal de classement, et la compression et le cache accélèrent les pages, ce qui compte bien.
Où coller le correctif ?
Sur Apache, dans .htaccess avec mod_headers activé. Avec Nginx, cela va dans le bloc server. Sur Netlify ou Cloudflare Pages, dans un fichier _headers à la racine du site.
La politique de contenu va-t-elle casser mon site ?
Pas celle écrite ici, car elle est en Report-Only. Elle ne bloque rien et, au contraire, liste ce qu’une politique active arrêterait.
Pourquoi mon score diffère-t-il d’autres outils ?
Chaque outil pondère les lignes à sa façon. De plus, celui-ci compte la compression et le cache, que les scanners de sécurité purs ignorent.
J’utilise WordPress. Qui ajoute ces en-têtes ?
En général du serveur ou d’une extension. C’est pourquoi les lignes .htaccess fonctionnent sur la plupart des hébergements WordPress sous Apache.
Pourquoi la compression n’est-elle pas mesurée ?
La seconde connexion, celle qui demande gzip, n’a pas abouti. La ligne reste donc sans verdict au lieu d’être devinée.
En quoi est-il différent du vérificateur de code de statut ?
Le vérificateur de code de statut montre ce que répond une adresse et où elle redirige. En revanche, celui-ci note les en-têtes de cette réponse et écrit le correctif.
L’adresse vérifiée est-elle stockée ?
Non. Elle sert à une seule vérification puis disparaît, et rien n’est journalisé.
Outils pour vérifier un serveur
Les en-têtes sont une couche de la réponse. Ces trois outils vérifient les autres.
Voyez quel code renvoie chaque URL
Le statut que renvoie une adresse, et chaque saut en chemin.
Ouvrir l’outil →Expiration du certificat, noms couverts et confiance des navigateurs.
Ouvrir l’outil →Vérificateur de chaînes de redirection
Chaque saut entre l’adresse tapée et la page finale.
Ouvrir l’outil →
Prêt à vérifier vos en-têtes ?
Collez une adresse, lisez la note et copiez le correctif pour votre serveur. Le vérificateur d’en-têtes HTTP est gratuit, sans compte, et ne garde aucune trace.