Un scan externe passif. Chaque constatation contient l'observation brute effectuée par le scanner
et une commande que vous pouvez exécuter vous-même pour la reproduire - rien n'est écrit par un modèle.
14 groupes de vérification :
Résolution DNS et vérification des enregistrements CAA · Vérification de SPF et DMARC · Inspection du certificat TLS et des versions de protocole · Test de la redirection HTTP vers HTTPS · Lecture des en-têtes de sécurité de la réponse · Vérification des attributs des cookies · Analyse de la politique CORS · Recherche de bannières de version · Vérification des méthodes HTTP autorisées · Analyse de la page d'accueil à la recherche de contenu mixte et de formulaires non sécurisés · Recherche de fichiers de configuration et de contrôle de version exposés · Vérification de la présence de listages de répertoires · Lecture de robots.txt et security.txt · Vérification des ports de service exposés
Démarrage…
0%
À propos Analyse de sécurité de site web
Beaucoup de scanners vous donnent une note en lettre et une liste de mots inquiétants. Celui-ci donne aussi une note, mais chaque point retiré est lié à un constat qui montre la réponse réellement obtenue et la commande d'une ligne qui vous renvoie la même réponse : un constat se vérifie, il n'a pas à être cru sur parole.
Ce qu'il fait
Vérifie DNS et CAA, SPF et DMARC, le certificat TLS et TLS 1.0/1.1, la redirection vers HTTPS, les en-têtes de sécurité, les attributs des cookies, CORS, les bannières de version, les méthodes HTTP, le contenu mixte, 23 chemins sensibles, les listages de répertoires, robots.txt, security.txt et 12 ports de service.
Chaque résultat comporte l'observation brute et une commande shell pour le reproduire.
Les vérifications qui n'ont pas pu s'exécuter sont signalées comme "non vérifié", jamais silencieusement comme réussies.
Les rapports se téléchargent en Markdown ou en JSON.
Comment ça marche
1Saisissez un domaine dont vous êtes responsable.
2L'analyse effectue des sondages passifs : des requêtes ordinaires, sans exploitation.
3Lisez les résultats, chacun avec sa preuve, et vérifiez ceux qui comptent.
Aucun résultat n'est inventé
Le scanner ne contient aucun modèle de langage. La gravité, l'impact et la correction sont fixés pour chaque contrôle, et chaque constat est produit à partir d'une observation réelle. Le rapport affiché et les téléchargements Markdown et JSON sont construits à partir des mêmes constats, sans aucun modèle.
Comment la note est calculée
Le score part de 100 et perd 34 points par constat critique, 13 par élevé, 5 par moyen et 1,5 par faible, avec un plafond par gravité (élevé 45, moyen 22, faible 9). Les résultats informatifs et réussis ne coûtent rien. 90 et plus donne un A, 75 un B, 60 un C, 40 un D, en dessous un F. Un seul fichier .env exposé ou un port de base de données joignable fait passer un site sans défaut de 100 à 66, un C ; deux constats de ce type donnent 32, un F.
Éviter les fausses alertes
Avant de sonder des chemins comme /.git/HEAD ou /backup.sql, le scanner demande une adresse aléatoire qui ne peut pas exister et note la réponse du site. Un chemin n'est signalé comme exposé que s'il renvoie HTTP 200, diffère de cette réponse de référence et correspond à la signature propre du fichier : un site qui répond à toute URL par sa page d'accueil ne se couvre donc pas de constats critiques.
Un rapport propre n'est pas un certificat
Ce sont des vérifications passives sur un site en fonctionnement. Elles ne couvrent pas la logique applicative, l'authentification, le contrôle d'accès, ni rien derrière une connexion - les endroits où les vraies violations commencent généralement. Les vérifications qui n'ont pas pu se terminer sont listées comme non vérifiées pour cette raison précise : une réussite issue d'une connexion échouée est une fausse réassurance, et une analyse sans résultat signifie que rien n'a été trouvé, pas que rien n'existe.
N'analysez que ce qui vous appartient
Analysez des domaines que vous possédez ou pour lesquels vous avez une autorisation écrite de test. L'outil refuse les hôtes qui résolvent vers des adresses privées ou internes, et il est limité en débit par IP, mais l'autorisation reste votre responsabilité.
Questions
Est-ce une attaque active ?
Non. Il envoie des requêtes GET, HEAD et OPTIONS ordinaires, effectue des négociations TLS (y compris des tentatives en TLS 1.0 et 1.1), des requêtes DNS via le DNS sur HTTPS de Cloudflare et de simples connexions TCP vers 12 ports. Rien n'est exploité, aucun formulaire n'est envoyé et rien n'est modifié.
Puis-je analyser n'importe quel site web ?
Seulement ceux que vous possédez ou que vous êtes autorisé à tester. Analyser une infrastructure tierce sans permission peut être illégal là où vous vous trouvez.
Pourquoi une vérification indique-t-elle "non vérifié" ?
Parce qu'elle n'a pas pu être terminée - généralement parce que rien n'a répondu sur cette origine. C'est signalé honnêtement plutôt qu'enregistré comme une réussite.
Puis-je exporter le rapport ?
Oui, en Markdown ou en JSON, pendant une heure : le rapport reste en cache sur le serveur ce temps-là pour que les téléchargements fonctionnent, puis expire. Aucun export ne fait appel à un modèle. Le relevé d'utilisation garde le nombre de constats et la note, pas le domaine.
Quels fichiers et ports sont testés ?
Fichiers : 23 chemins fixes, dont /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env, chacun signalé seulement si la réponse correspond à la signature propre de ce fichier ; /.well-known/security.txt compte en votre faveur s'il est publié. Ports : une simple connexion TCP, jamais une tentative d'authentification, vers 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080. Un port de base de données joignable (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) ou Telnet est classé critique.
Que signalent les contrôles SPF et DMARC ?
Les deux enregistrements sont lus dans le DNS public, même pour un site qui n'envoie pas d'e-mails, car sans eux n'importe qui peut envoyer un e-mail prétendant venir de votre domaine. Pas d'enregistrement SPF : gravité moyenne ; un SPF contenant +all, qui autorise tous les serveurs d'internet : élevée. Pas d'enregistrement DMARC sous _dmarc : moyenne ; p=none (ou aucune balise p=) ne fait que surveiller : faible ; p=quarantine ou p=reject est validé. Un domaine qui n'envoie aucun e-mail peut publier v=spf1 -all.
Quels en-têtes de sécurité sont vérifiés, et quelle valeur est validée ?
Six en-têtes dans la réponse de votre page d'accueil. S'ils manquent, HSTS et Content-Security-Policy sont de gravité élevée, X-Content-Type-Options et X-Frame-Options moyenne, Referrer-Policy et Permissions-Policy faible. Strict-Transport-Security demande un max-age d'au moins 15552000 (180 jours) : plus court, c'est faible ; max-age=0, c'est moyen. Content-Security-Policy est signalée comme affaiblie (moyenne) si script-src autorise 'unsafe-inline', si la politique autorise 'unsafe-eval' ou si default-src ou script-src contient un joker * seul. X-Content-Type-Options doit valoir exactement nosniff. X-Frame-Options doit valoir DENY ou SAMEORIGIN, et n'est pas nécessaire si la CSP définit frame-ancestors. Referrer-Policy n'est signalée que pour unsafe-url ou no-referrer-when-downgrade. Permissions-Policy doit seulement être présente. Chaque en-tête absent ou faible est accompagné d'une commande curl -sI pour vérifier vous-même.
Comment vérifie-t-il les attributs des cookies (Secure, HttpOnly, SameSite) ?
Il lit chaque en-tête Set-Cookie de la réponse de votre page d'accueil (jusqu'à 12 cookies) et vérifie pour chacun Secure, HttpOnly et SameSite. L'absence de Secure ou de HttpOnly est de gravité moyenne ; l'absence de SameSite seule est faible, et SameSite=None sans Secure est signalé parce que les navigateurs refusent ce cookie. Un cookie qui a les trois attributs est validé. La correction habituelle est Secure; HttpOnly; SameSite=Lax (sous Django : SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY et SESSION_COOKIE_SAMESITE). L'analyse n'est pas connectée : les cookies créés seulement après la connexion ne sont pas vus. Vérifiez vous-même avec curl -sI https://your-site/ | grep -i set-cookie
Comment fonctionne le contrôle CORS, et quand est-il critique ?
Il envoie une requête GET à votre page d'accueil avec Origin: https://scanner-probe.example et lit Access-Control-Allow-Origin et Access-Control-Allow-Credentials dans la réponse. Pas d'en-tête Access-Control-Allow-Origin, ou une origine fixe qui ne renvoie pas celle du test : c'est validé. Renvoyer l'origine du test avec Access-Control-Allow-Credentials: true est critique, car n'importe quel site visité par un utilisateur connecté pourrait lire ses réponses. Renvoyer l'origine sans identifiants est moyen. Un joker * est faible, ou moyen si les identifiants sont aussi autorisés (les navigateurs refusent cette combinaison). Seule la page d'accueil est testée et aucune requête préliminaire OPTIONS n'est envoyée : testez vos routes d'API à part avec curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control
Que vérifie le contrôle TLS (expiration du certificat, TLS 1.0 et 1.1) ?
Il se connecte au port 443 et valide la chaîne de certificats et le nom d'hôte. Un certificat qui ne se valide pas est de gravité élevée, un certificat expiré est en plus signalé critique, et un certificat à moins de 15 jours de l'échéance est moyen ; sinon le sujet, l'émetteur, la date d'expiration et les noms SAN sont affichés comme validés. Le protocole négocié doit être TLS 1.2 ou TLS 1.3, toute version plus ancienne est élevée. Il tente ensuite séparément une négociation TLS 1.0 et une négociation TLS 1.1 : un serveur qui accepte l'une ou l'autre reçoit un constat moyen, car les deux sont dépréciées par la RFC 8996. Si l'OpenSSL du scanner ne peut pas proposer l'ancienne version, rien n'est signalé plutôt que de deviner. Le correctif nginx est ssl_protocols TLSv1.2 TLSv1.3; Vérifiez les dates vous-même avec echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates
Vérifie-t-il que HTTP redirige vers HTTPS ?
Oui. Il demande http://your-site/ sans suivre les redirections. Un 301 ou un 308 vers une adresse https:// est validé. Un 302, 303 ou 307 vers HTTPS est faible, car les navigateurs ne mémorisent pas une redirection temporaire et chaque nouvelle visite commence par une requête non chiffrée. Une page servie en HTTP non chiffré (réponse 2xx) est élevée. Si le port 80 ne répond pas du tout, c'est informatif, pas un échec. Le correctif nginx est server { listen 80; return 301 https://$host$request_uri; }, puis ajoutez Strict-Transport-Security. Vérifiez vous-même avec curl -I http://your-site/
Il envoie une seule requête OPTIONS à votre page d'accueil et lit l'en-tête Allow, ou Access-Control-Allow-Methods si Allow est absent. TRACE, TRACK, PUT ou DELETE annoncé est moyen ; PATCH ou CONNECT seuls sont faibles ; uniquement des méthodes de lecture standard est validé. Si le serveur n'envoie aucun des deux en-têtes, rien n'est signalé. Annoncer une méthode ne prouve pas qu'elle fonctionne : vérifiez avant de modifier quoi que ce soit. TRACE peut renvoyer à l'appelant les en-têtes de la requête, cookies compris (Cross-Site Tracing). nginx refuse TRACE par défaut ; sous Apache, réglez TraceEnable Off. Réservez PUT et DELETE aux routes d'API qui en ont besoin, derrière une authentification. Vérifiez vous-même avec curl -X OPTIONS -i https://your-site/
Comment détecte-t-il le listage de répertoires ("Index of /") ?
Il demande 7 chemins : /, /static/, /assets/, /uploads/, /images/, /files/ et /backup/. Un chemin qui répond HTTP 200 avec une page dont la balise title ou le titre principal commence par "Index of /" est signalé comme moyen (CWE-548), car le listage montre des fichiers liés nulle part, comme des sauvegardes, des exports et d'anciennes versions. Si aucun ne le fait, la vérification est validée ; si le site est injoignable, elle est indiquée comme non effectuée. Le correctif nginx est autoindex off; (la valeur par défaut, cherchez donc un autoindex on explicite), sous Apache Options -Indexes, puis sortez tout fichier sensible de la racine web. Vérifiez vous-même avec curl -s https://your-site/uploads/ | head -20
Détecte-t-il le contenu mixte et les formulaires envoyés en HTTP ?
Oui, sur la page d'accueil. Il lit le HTML tel qu'il est servi (aucun JavaScript n'est exécuté) et liste chaque balise script, link, iframe ou img dont le src ou le href commence par http://. Si l'une d'elles est un fichier .js ou .css, le constat est moyen, car un script ou une feuille de style remplacés en transit s'exécutent dans votre page HTTPS ; des images et des cadres seuls donnent faible ; aucune, c'est validé (CWE-311). Un formulaire dont l'action commence par http:// est classé élevé (CWE-319), car tout ce qu'on y saisit, mots de passe compris, part en clair. La correction : passer ces URL en https:// ou en relatif, et ajouter l'en-tête Content-Security-Policy: upgrade-insecure-requests comme filet de sécurité. Vérifiez vous-même avec curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"
Que vérifie-t-il dans robots.txt et security.txt ?
robots.txt : il récupère /robots.txt et, s'il répond HTTP 200 sous forme de fichier texte, lit les lignes Disallow de ses 8000 premiers caractères. Un chemin Disallow contenant admin, internal, private, backup, config, staging, test, api, secret, dev est classé faible (CWE-200) : robots.txt est public et demande seulement aux robots respectueux de ne pas venir, donc lister ces chemins les signale. Protégez-les par une authentification et utilisez noindex pour garder des pages hors des moteurs. security.txt : il demande /.well-known/security.txt, l'emplacement fixé par la RFC 9116, et le compte en votre faveur quand le fichier a une ligne Contact:. Un fichier absent ne fait pas perdre de points. La RFC 9116 exige aussi un champ Expires:, que le scan ne vérifie pas, donc publiez les deux, par exemple Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z. Vérifiez vous-même avec curl -s https://your-site/.well-known/security.txt
Que recherche le contrôle CAA et comment ajouter un enregistrement CAA ?
Il interroge les enregistrements CAA (RFC 8659) du nom d'hôte saisi, via le DNS sur HTTPS de Cloudflare. S'il en trouve, le contrôle est validé et la preuve en affiche jusqu'à 5 ; s'il n'en trouve aucun, il signale "No CAA record" en gravité faible, car n'importe quelle autorité de certification publique peut alors émettre un certificat pour ce nom. Un enregistrement CAA liste les AC que vous utilisez réellement, par exemple your-site. IN CAA 0 issue "letsencrypt.org", plus 0 iodef "mailto:security@your-site" pour recevoir les signalements. Ajoutez une ligne issue par AC utilisée, et une ligne issuewild si les certificats génériques (wildcard) doivent venir d'une autre AC. Vérifiez vous-même avec dig CAA your-site
Pourquoi l'analyse de www ou d'un sous-domaine indique-t-elle l'absence de CAA, SPF ou DMARC ?
Chaque contrôle DNS porte sur le nom exact saisi : www.example.com est interrogé comme www.example.com, pas comme example.com, et les trois enregistrements ne s'héritent pas de la même façon. CAA : une autorité de certification qui ne trouve aucun enregistrement CAA sur www.example.com remonte à example.com et utilise celui-ci (RFC 8659, section 3), donc "No CAA record" sur un sous-domaine peut être une fausse alerte. DMARC : les destinataires se rabattent sur la politique du domaine organisationnel, qui peut fixer une politique distincte pour les sous-domaines avec sp= (RFC 9989, qui rend obsolète la RFC 7489), donc l'absence d'enregistrement sur _dmarc.www.example.com est en général couverte par _dmarc.example.com. SPF : aucun héritage (RFC 7208), donc "No SPF record" est exact pour ce nom ; un nom d'hôte qui n'envoie aucun e-mail peut publier v=spf1 -all. Une requête DNS qui échoue apparaît aussi comme un enregistrement absent. Analysez aussi le domaine nu, ou confirmez avec dig CAA example.com et dig TXT _dmarc.example.com