Audit de configuration HTTPS — HSTS, cookies, contenu mixte et certificat
Audit de configuration HTTPS
Collez les en-têtes de réponse d’un site — et, si vous les avez, son certificat, un extrait de son source de page et le nom d’hôte — et cette page indique comment le volet HTTPS est configuré : si HSTS est défini et pendant combien de temps, si une politique de sécurité de contenu met à niveau les requêtes non sécurisées, si les cookies sont marqués Secure et SameSite, si une bannière de serveur révèle une version, et ce que disent les en-têtes de proxy sur la requête telle que l’application l’a vue. Le certificat est audité dans le même rapport, les sous-ressources http:// simples sont comptées dans le source de la page, et les commandes capables de voir la négociation TLS sont listées pour que vous les exécutiez vous-même. Tout s’exécute dans votre navigateur, et la page n’émet aucune requête de son propre chef.
1. En-têtes de réponse
Le bloc d’en-têtes de réponse complet, ligne d’état comprise. La source la plus simple : curl -sI https://example.com/ dans un terminal, ou le panneau Headers de l’onglet Réseau des outils de développement du navigateur, copié depuis le haut du fichier. Les en-têtes supplémentaires sont lus puis ignorés ; seuls ceux qui concernent HTTPS sont signalés.
2. Certificat ou chaîne (facultatif)
Une fois ce champ rempli, le même rapport contient aussi l’audit complet du certificat, de sorte que configuration et certificat sont lus ensemble. Le PEM, un corps nu en base64 ou en hexadécimal et un .p7b PKCS#7 fonctionnent tous ; le vérificateur de certificat approfondit le certificat isolément.
3. Extrait du source de la page (facultatif)
Collez le source de la page (ou seulement les balises contenant des URL) et chaque adresse http:// simple est listée, car une sous-ressource chargée en HTTP casse le cadenas et peut être réécrite en transit, même si la page elle-même est arrivée en HTTPS. Les adresses pointant vers l’hôte propre du site sont signalées à part, puisque ce sont celles qu’une URL relative corrigerait.
4. Nom d’hôte (facultatif)
Avec un nom d’hôte ici, l’audit vérifie les noms alternatifs du sujet comme le ferait un navigateur, y compris les règles des jokers, et compare les adresses http:// simples à ces noms.
aucun audit encore
L’exemple est volontairement imparfait, afin que chaque partie du rapport ait quelque chose à montrer : un bloc d’en-têtes avec HSTS et une politique de sécurité de contenu (mais sans preload, et un cookie sans SameSite), une chaîne de deux certificats, et un extrait de page qui charge un script en http:// simple et pointe une image vers l’hôte propre du site de la même façon. Attendez-vous à un F sur l’exemple et lisez les constats en dessous pour comprendre chacun.
Ce qui est vérifié. À partir du bloc d’en-têtes : HSTS, son max-age, includeSubDomains et preload ; une politique de sécurité de contenu qui met à niveau les requêtes non sécurisées ; les attributs Secure, HttpOnly et SameSite de chaque Set-Cookie ; une bannière de serveur qui nomme un produit et une version ; et les en-têtes de transfert qui indiquent si l’application a vu la requête comme HTTPS. À partir du bloc de certificat : l’audit complet du certificat, jusqu’à savoir si chaque maillon de la chaîne a bien signé le suivant. À partir du source de la page : les sous-ressources http:// simples. Les trois sont signalés séparément puis résumés ensemble, car un cadenas brisé relève en général de l’un de ces trois et non des deux autres. Pour la liste OWASP complète des en-têtes de réponse de sécurité — X-Content-Type-Options, protection contre l’encadrement, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP et la note — collez le même bloc d’en-têtes dans la page Contrôle des en-têtes de sécurité ; les deux pages se répartissent le travail entre la couche TLS et la couche des en-têtes.
Ce qu’elle ne peut pas voir. Cette page n’ouvre jamais de connexion TLS. Les navigateurs n’exposent pas la négociation à une page, si bien que la version du protocole, la suite de chiffrement, le groupe d’échange de clés, l’agrafage OCSP, la reprise de session, le 0-RTT, la chaîne de certificats qu’un serveur en activité envoie réellement, et la question de savoir si une redirection HTTP vers HTTPS a lieu à l’origine ou sur un proxy, sont tous hors de portée de n’importe quelle page web. Elle ne peut pas non plus interroger un site tiers pour récupérer les en-têtes à votre place, ni dire si un certificat est approuvé, car cela dépend d’un magasin de racines qu’une page ne peut pas lire. Les commandes plus bas sur cette page voient ces éléments, et c’est à vous de les exécuter sur votre propre machine.
Où obtenir le bloc d’en-têtes. Dans un terminal, curl -sI https://example.com/ affiche exactement ce que demande cette page. Dans un navigateur, ouvrez les outils de développement, allez dans l’onglet Réseau, rechargez la page, sélectionnez la requête du document et copiez toute la zone Response Headers, ou utilisez Copier → Copier les en-têtes de réponse. Pour le contrôle de redirection, lancez aussi curl -sI http://example.com/ et collez les deux blocs : la page les rapporte l’un après l’autre.
Rapport d’audit
Aucun audit encore. Collez un bloc d’en-têtes ci-dessus et appuyez sur Auditer cette configuration pour le rapport complet ; un certificat, un extrait de source de page et un nom d’hôte sont facultatifs, et chacun ajoute sa propre section.
Sonde d’accessibilité — la seule partie de cette page qui utilise le réseau
Une page ne peut pas ouvrir de connexion TLS, mais elle peut tenter une requête ordinaire. Si le site autorise les lectures inter-origines, l’URL à laquelle aboutit la réponse indique si http:// a été redirigé vers https://, et c’est tout ce que cela peut prouver. Si la requête échoue, cette page ne peut pas dire si l’hôte est en panne, si votre propre connexion l’est, ou si le site n’autorise simplement pas les lectures inter-origines — cette dernière éventualité est la plus courante, car la plupart des sites n’envoient pas Access-Control-Allow-Origin. Une URL http:// reçoit une réponse avant toute redirection, c’est donc la seule chose ici que le navigateur tentera sur une connexion simple. Rien ne quitte le navigateur tant que vous n’appuyez pas sur le bouton.
Ces commandes sont destinées à être exécutées par vous, sur une machine que vous contrôlez, contre un hôte que vous êtes autorisé à tester. La sortie de -showcerts peut être collée directement dans le vérificateur de certificat, et la sortie des en-têtes dans cette page.
Le certificat est un document public. Tout certificat publiquement approuvé est publié dans les journaux de transparence des certificats, de sorte que n’importe quel nom d’hôte qu’il contient — y compris un nom interne ou mal saisi qu’une autorité de certification publique a signé — peut être trouvé en interrogeant ces journaux. Un certificat porte aussi les adresses de révocation que son émetteur a choisies, et celles-ci nomment parfois un hôte interne. C’est pourquoi le certificat servi par un CDN ne dit rien du serveur d’origine : les noms qu’il contient appartiennent au CDN. Si l’audit fait apparaître un nom d’hôte que vous n’attendiez pas, considérez-le comme public et remplacez ce qu’il protège.
Confidentialité : le bloc d’en-têtes, le certificat et le source de la page sont lus localement et jamais envoyés, et aucune requête d’aucune sorte n’est effectuée à moins d’appuyer sur le bouton sonde d’accessibilité. Pour créer votre propre certificat, utilisez le générateur de certificats auto-signés ; pour vérifier qu’une clé privée appartient à un certificat, utilisez le comparateur certificat et clé.
🔐 Outils SSL et TLS
Utilitaires de certificats et de clés qui fonctionnent entièrement dans votre navigateur.