Un scanner gratuit qui vérifie le certificat SSL et les en-têtes HTTP donne une fausse impression de couverture. L’OWASP Top 10:2025 place Security Misconfiguration en deuxième position et introduit Software Supply Chain Failures comme catégorie à part entière. Tester la sécurité d’un site web en ligne suppose de comprendre ce que ces outils captent réellement, et surtout ce qu’ils ignorent.
Supply Chain et conditions exceptionnelles : les angles morts des scanners gratuits
La plupart des outils accessibles sans inscription analysent la surface exposée : validité du certificat TLS, présence des en-têtes Content-Security-Policy, X-Frame-Options, configuration DNS. C’est un socle utile, mais qui ne couvre ni la chaîne de dépendances logicielles ni la gestion des erreurs applicatives.
L’OWASP Top 10:2025 a formalisé ces deux risques sous les catégories Software Supply Chain Failures et Mishandling of Exceptional Conditions. Un composant JavaScript importé via npm, une image Docker construite sur une base non maintenue, un pipeline CI/CD dont les secrets sont exposés : aucun scan externe anonyme ne détecte ces défauts.
Nous recommandons de traiter le scan en ligne comme un premier filtre, pas comme un audit. Il identifie les erreurs de configuration visibles depuis l’extérieur. Pour la chaîne logicielle, il faut un outil de type Software Composition Analysis (Snyk Open Source, OWASP Dependency-Check) exécuté dans le dépôt de code.
Avant de lancer un scan, il est utile de tester la sécurité d’un site web en ligne en comprenant précisément le périmètre couvert par chaque outil, afin d’éviter de confondre un rapport propre avec une surface d’attaque réellement réduite.
Security Misconfiguration : ce que les scans d’en-têtes HTTP détectent vraiment
La montée de Security Misconfiguration au deuxième rang du classement OWASP n’est pas anecdotique. Elle reflète la multiplication des surfaces de configuration : buckets cloud publics, endpoints d’administration accessibles, pages d’erreur verbeuses qui exposent des traces de pile, cookies sans attribut Secure ou SameSite.
Les scanners gratuits couvrent une partie de ce périmètre. Ils vérifient typiquement :
- La présence et la valeur des en-têtes de sécurité HTTP (Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
- La configuration TLS (version du protocole, suites de chiffrement, expiration du certificat)
- L’exposition d’informations serveur dans les en-têtes de réponse (Server, X-Powered-By)
- La politique CORS et les origines autorisées
En revanche, un scan externe ne teste pas les configurations internes : règles IAM d’un bucket S3, accès à une console d’administration protégée par une URL obscure, ou variables d’environnement injectées en clair dans le code source côté client. Ces vérifications exigent un accès authentifié ou un audit du code déployé.
Interpréter un score de sécurité sans le surévaluer
Un rapport affichant un score élevé (A ou A+) sur les en-têtes HTTP ne signifie pas que l’application est sûre. Il signifie que la couche transport et les directives navigateur sont correctement paramétrées. Nous observons régulièrement des sites notés A+ dont le panneau d’administration est accessible via /admin sans restriction IP ni double authentification.
Le score est un indicateur de maturité sur un périmètre précis. Il ne couvre ni la logique métier ni les contrôles d’accès applicatifs.
Broken Access Control et tests authentifiés : la limite structurelle du scan anonyme
Le risque classé numéro un par l’OWASP en 2025 reste Broken Access Control, qui inclut désormais le SSRF (Server-Side Request Forgery). Ce type de vulnérabilité nécessite des comptes de test avec plusieurs niveaux de privilèges et des scénarios métier concrets : un utilisateur standard qui tente d’accéder à une ressource réservée à un administrateur, une requête API qui modifie l’identifiant d’un objet pour atteindre les données d’un autre utilisateur (IDOR).
Aucun scanner externe anonyme ne peut valider les contrôles d’accès sans disposer d’au moins deux sessions authentifiées avec des rôles différents. Un outil comme OWASP ZAP permet de configurer des contextes d’authentification et de rejouer des scénarios, mais cela dépasse le cadre d’un simple test en ligne.
Approche combinée pour un audit réaliste sans budget
Pour couvrir un périmètre acceptable sans investissement financier, nous recommandons de combiner trois couches :
- Un scan d’en-têtes et de configuration TLS via un outil en ligne gratuit (Mozilla Observatory, SecurityHeaders.com) pour le périmètre réseau et transport
- Un proxy d’interception local (OWASP ZAP en mode standard) pour tester manuellement les contrôles d’accès et les injections sur les formulaires, avec des sessions authentifiées
- Une analyse de dépendances (npm audit, pip-audit, OWASP Dependency-Check) directement dans le pipeline de build pour couvrir la chaîne logicielle
Cette combinaison couvre trois des cinq premiers risques du classement OWASP 2025. Elle ne remplace pas un pentest professionnel, mais elle élève significativement le niveau de détection par rapport à un scan unique d’en-têtes HTTP.
CORS, cookies et Content-Security-Policy : les réglages à vérifier en priorité
Parmi les éléments testables gratuitement, trois configurations concentrent une part disproportionnée des erreurs exploitables.
La politique CORS mal configurée reste fréquente. Un Access-Control-Allow-Origin positionné sur * avec Access-Control-Allow-Credentials à true expose les cookies de session à tout domaine tiers. Les scanners gratuits signalent cette combinaison, mais ne testent pas les conséquences applicatives.
Les attributs de cookies méritent une attention particulière. Un cookie de session sans Secure, sans HttpOnly et sans SameSite=Strict (ou Lax) est vulnérable au vol via XSS ou à l’inclusion dans des requêtes cross-site. Les navigateurs récents atténuent certains scénarios, mais la configuration explicite reste la seule protection fiable côté serveur.
Enfin, une Content-Security-Policy permissive annule la protection contre les injections XSS. Une directive script-src contenant ‘unsafe-inline’ ou ‘unsafe-eval’ rend la CSP cosmétique. Les outils de scan en ligne détectent ces directives, ce qui en fait un des rares contrôles applicatifs accessibles sans authentification.
La gratuité d’un outil de test ne pose pas de problème en soi. Ce qui crée un faux sentiment de sécurité, c’est de traiter le rapport comme exhaustif alors qu’il ne couvre qu’une fraction de la surface d’attaque réelle. Un scan propre sur les en-têtes HTTP reste un bon point de départ, à condition d’enchaîner avec les couches que l’outil ne peut pas atteindre.
