Comment fonctionne cette vérification
Scanaris extrait tous les commentaires HTML de ta page principale, c'est-à-dire tout ce qui se trouve entre <!-- et -->, et y cherche six motifs de secret. Quatre sont des formats de clé reconnaissables : clés secrètes Stripe (sk_live_ suivi de 20 caractères ou plus), clés d'accès AWS (AKIA et 16 caractères), clés d'API Google (AIza et 35 caractères) et en-têtes de clé privée (-----BEGIN PRIVATE KEY----- et les variantes RSA ou EC). Les deux autres sont des affectations explicites : password, passwd ou pwd suivis d'une valeur d'au moins 6 caractères, et api_key, secret, token ou bearer suivis d'une valeur d'au moins 16. Si l'un correspond, il ouvre un constat de sévérité élevée qui indique le type de secret trouvé, jamais la valeur. Les motifs sont stricts à dessein : un commentaire qui dit « le jeton va ici » sans valeur derrière n'est pas signalé.
Pourquoi c'est important
Les commentaires HTML ne se voient pas sur la page, mais ils se voient dans le code source, et n'importe qui voit le code source avec Ctrl+U ou un curl. Il n'y a aucune différence pratique entre mettre une clé dans un commentaire et la publier sur un forum. Une clé secrète Stripe permet de créer des paiements et des remboursements ; une clé AWS, d'utiliser ton compte et ta facture ; un mot de passe de base de données, de tout lire. Et les chasseurs de secrets automatisés parcourent tout le web à la recherche de ces préfixes précis, donc le délai entre la publication de la clé et son utilisation se compte en minutes.
D'où ça vient
Quelqu'un se laisse une note pendant le développement (« <!-- utilisateur admin / password Temporaire2024 --> »), met en commentaire un bloc de configuration « pour tester » au lieu de le supprimer, ou colle un exemple d'intégration avec la vraie clé. Les templates WordPress et les sites statiques faits à la main sont les plus exposés, parce que leurs commentaires arrivent tels quels au navigateur. Dans les frameworks modernes ça arrive moins, mais ça arrive : un commentaire dans un .html statique du dossier public ou dans un composant qui n'est pas compilé.
Comment corriger
- Fais tourner la clé d'abord. Pars du principe qu'elle a déjà été lue. Génères-en une nouvelle chez le fournisseur, change-la sur ton serveur et révoque l'ancienne. Ensuite supprime le commentaire ; pas l'inverse.
- Cherche dans le projet avant de déployer, pas seulement dans la page principale :
grep -rnE "sk_live_|AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35}|BEGIN (RSA |EC )?PRIVATE KEY|(password|api_key|secret|token)\s*[:=]" --include=*.html --include=*.vue --include=*.php --include=*.hbs .- Supprime les commentaires en production. Vue et Nuxt les retirent à la compilation ; dans Next.js, les commentaires JSX n'atteignent jamais le HTML. Pour du HTML statique ou WordPress, un minificateur (
html-minifier-terseravecremoveComments) ou le plugin d'optimisation que tu utilises les élimine. En PHP, utilise des commentaires PHP (<?php // ... ?>), qui ne sortent pas du serveur. - Les identifiants vont dans des variables d'environnement, jamais dans des fichiers servis. Et ajoute un détecteur de secrets au dépôt (
gitleaksou l'analyse de secrets de GitHub) pour que ça ne revienne pas.
Vérifie que c'est corrigé
curl -s https://tondomaine.com | tr -d '\n' | grep -oE '<!--.{0,200}' | grep -iE "sk_live_|AKIA|AIza|PRIVATE KEY|password|api_key|secret|token|bearer"Rien ne doit sortir. L'idéal est que la première partie, sans le dernier filtre, ne renvoie aucun commentaire non plus : en production ils ne servent à rien.
Questions fréquentes
C'est une clé de test, pas de production.
Les motifs font la différence : le sk_test_ de Stripe n'est pas signalé, sk_live_ si. Si le constat est apparu, c'est que le format correspond à une vraie clé ou à une affectation explicite de mot de passe. Si c'est vraiment une valeur fictive, remplace-la par quelque chose qui ne ressemble pas à un identifiant, comme A_REMPLACER.
Les commentaires du JavaScript sont-ils aussi examinés ?
Cette vérification ne regarde que le HTML. Les clés dans les bundles JavaScript, en commentaire ou non, sont cherchées par secrets dans le JavaScript, et les références à des hôtes internes par références internes. Ce qui fuit d'autre sans le vouloir est dans les secrets que ton appli laisse fuir dans le navigateur.
Les commentaires conditionnels d'Internet Explorer comptent-ils ?
Ce sont des commentaires HTML et ils sont analysés de la même façon, mais ils ne contiennent pas de secrets et ne sont pas signalés. Cela dit, en 2026 ils sont inutiles : aucun navigateur pris en charge ne les interprète.