Sécurité offensive
Gouvernance & conformité
Protection des données
Le contrôle d'accès défaillant occupe la première place du Top 10 de l'OWASP depuis l'édition 2021, devant les défauts cryptographiques et les injections. C'est aussi la famille de failles qu'un scanner automatique détecte le plus mal, parce qu'elle suppose de comparer les droits de deux comptes distincts et de comprendre qui a le droit de voir quoi. Un outil qui lit des en-têtes HTTP ne raisonne pas comme cela. Vouloir tester la sécurité de son site web reste une démarche saine, et les scanners publics ont leur utilité. Ils répondent simplement à une question plus étroite que celle que se pose un dirigeant.
Chez Digitemis, cabinet qualifié PASSI par l'ANSSI, nous menons des tests d'intrusion applicatifs pour des organisations qui doivent à la fois se protéger, se conformer et continuer à produire leur service en ligne. Cet article détaille ce qu'un outil gratuit voit réellement, ce qu'il ne verra jamais, et à quel moment un scan cesse de suffire.
Les trois couches d'un site exposé
La configuration et l'infrastructure
La première chose à regarder, c'est la manière dont le serveur parle au reste du monde. Configuration du serveur web (Apache, Nginx, IIS), paramétrage des suites cryptographiques TLS, présence et cohérence des en-têtes de sécurité. Cette couche est publique par nature, donc facile à auditer de l'extérieur, y compris automatiquement. Elle détermine si les données en transit sont protégées et si le navigateur du visiteur reçoit les instructions qui bloquent les attaques génériques, du détournement de clic à l'injection de scripts tiers.
C'est la couche où les outils gratuits sont le plus pertinents. C'est aussi celle qui produit les plus beaux scores sans rien garantir de ce qui se passe derrière.
Les composants et bibliothèques tierces
Un site s'appuie aujourd'hui sur des dizaines, parfois des centaines de dépendances : CMS, thèmes, extensions, frameworks JavaScript, bibliothèques de traitement d'images ou de génération de PDF. Recenser ces composants et vérifier s'ils portent des vulnérabilités publiées (CVE) fait partie du minimum. Une extension abandonnée depuis deux ans devient une porte d'entrée le jour où quelqu'un publie un exploit.
Être à jour ne règle pas tout. Un composant récent peut contenir une faille non encore découverte, ou fonctionner chez vous dans une configuration que son éditeur n'a jamais prévue. Le suivi des versions traite le risque connu, pas le risque spécifique.
La logique applicative et métier
Ici commence la partie que personne ne peut auditer à votre place sans regarder votre application. Le tunnel de commande, la procédure de récupération de mot de passe, la gestion des rôles dans un espace client, l'export de données par un utilisateur : ces processus sont propres à votre organisation. Un scanner ne sait pas si un utilisateur devrait pouvoir consulter le panier d'un autre en changeant un identifiant dans l'URL, parce qu'il ne sait pas ce qu'est un panier.
Cette couche concentre l'essentiel des compromissions profondes. Elle demande un opérateur qui comprend le métier avant de comprendre le protocole.
Le cadre légal du test
L'autorisation écrite préalable
Avant de lancer le moindre outil, posez la question du mandat. Scanner un site que vous n'exploitez pas, ou pour lequel vous n'avez pas d'autorisation écrite, vous expose pénalement, quelle que soit votre intention. La formulation compte : « je voulais l'aider à corriger » n'est pas un moyen de défense. Une convention d'audit fixe le périmètre exact des cibles, les plages horaires, les techniques autorisées, les contacts d'escalade en cas d'incident. Nous n'engageons aucune mission sans ce document signé.
Le cas se complique quand le site est hébergé chez un prestataire ou construit sur un SaaS. Le contrat de service prévoit parfois une interdiction contractuelle de tester, y compris sur votre propre instance. Vérifiez les conditions générales avant, pas après.
L'article 323-1 du Code pénal
L'article 323-1 punit de trois ans d'emprisonnement et de 100 000 euros d'amende le fait d'accéder ou de se maintenir frauduleusement dans tout ou partie d'un système de traitement automatisé de données. Les peines montent lorsque l'accès entraîne une altération des données ou du fonctionnement du système. La tentative est punie des mêmes peines. Un scan agressif lancé sur le site d'un partenaire, même « pour voir », entre dans ce champ.
Retenez la règle simple : vous testez ce que vous exploitez, ou ce qui fait l'objet d'un mandat écrit. Rien d'autre.
Les vérifications manuelles à portée d'une équipe interne
Les en-têtes de sécurité HTTP
Ouvrez les outils de développement de votre navigateur, onglet Réseau, et regardez les en-têtes renvoyés par votre serveur. Content-Security-Policy restreint les sources de scripts autorisées et limite la portée d'un XSS. Strict-Transport-Security force le navigateur à ne plus jamais se connecter en clair. X-Content-Type-Options empêche le navigateur de deviner un type MIME à la place du serveur. Referrer-Policy évite de fuiter des URL internes vers des tiers.
Une CSP mal écrite, avec unsafe-inline sur toutes les directives, coûte plus cher en faux sentiment de sécurité qu'elle ne rapporte. Lisez la politique, ne vous contentez pas de constater sa présence.
La configuration TLS et le certificat
Un certificat valide est le point de départ, pas le résultat. Vérifiez que SSLv3, TLS 1.0 et TLS 1.1 sont désactivés, que les suites cryptographiques retenues assurent la confidentialité persistante (Forward Secrecy), et que la chaîne de certification est complète. Une clé privée compromise plus tard ne doit pas permettre de déchiffrer le trafic capturé aujourd'hui.
Regardez aussi les dates. Un renouvellement manuel oublié un vendredi soir produit une interruption de service dont personne ne veut porter la responsabilité.
Les fichiers et répertoires exposés
Les répertoires de versioning
Un dossier .git accessible à la racine permet de reconstituer le code source complet, historique compris, avec parfois les identifiants de base de données qu'un développeur avait commités puis retirés d'une version ultérieure. Testez l'accès à votre-site.com/.git/config. Si le fichier s'affiche, traitez le sujet le jour même.
Les fichiers de configuration et de sauvegarde
Les .env, config.php.bak, dump.sql ou web.config laissés en ligne après une maintenance donnent l'architecture interne et souvent des secrets exploitables. Ils ne sont référencés nulle part, ce qui rassure à tort : les listes de noms de fichiers courants circulent depuis quinze ans et un attaquant les teste en quelques secondes.
Les interfaces d'administration
/admin, /wp-admin, /phpmyadmin, les consoles de supervision et les interfaces de déploiement n'ont pas à être joignables depuis l'internet ouvert sans filtrage par adresse IP, VPN ou authentification multifacteur. Leur exposition ouvre la porte au bourrage d'identifiants et à l'exploitation immédiate de toute CVE publiée sur ces composants.
Les comptes par défaut
Une installation de service, un plugin, un environnement de recette cloné : chacun peut recréer un compte admin/admin ou un utilisateur de démonstration. La vérification prend quelques minutes sur les formulaires de connexion. Elle reste régulièrement négligée sur les environnements secondaires, qui pointent pourtant vers la même base de données que la production.
Les outils publics et leur périmètre réel
Les scanners passifs de surface
Mozilla Observatory, SecurityHeaders ou SSL Labs analysent votre site de l'extérieur sans tenter la moindre intrusion. Ils lisent des en-têtes, une configuration TLS, une politique de cookies. Le résultat décrit votre posture publique, et il est fiable dans ce périmètre. Une note médiocre montre que les bonnes pratiques de base ne sont pas tenues, ce qui est déjà une information de pilotage utile.
Une note « A+ » signifie que vos en-têtes sont bien configurés. Elle ne dit rien d'une injection SQL dans votre moteur de recherche interne.
Les scanners dynamiques (DAST)
OWASP ZAP, Nikto ou les versions communautaires d'outils commerciaux envoient des charges utiles pour provoquer des erreurs et repérer des vulnérabilités connues : XSS réfléchi, injections simples, fichiers exposés, méthodes HTTP dangereuses. Ils parcourent l'arborescence, remplissent les formulaires, comparent les réponses. Sur un site vitrine ou un CMS standard, ils remontent des choses réelles.
Leur rendement dépend de deux paramètres que peu d'équipes maîtrisent : la capacité de l'outil à s'authentifier et à conserver une session valide, et sa capacité à explorer une application riche en JavaScript. Un scanner qui se fait déconnecter au bout de trois requêtes teste la page de login, rien de plus. Et lancé sans précaution sur une production, il crée des milliers d'enregistrements parasites, déclenche des envois d'e-mails et sature parfois le service.
Ce que l'automatisation sait faire, et où elle s'arrête
L'automatisation est imbattable sur le volume : repérer une version vulnérable sur dix mille URL, vérifier une configuration sur cent domaines, refaire le contrôle chaque semaine sans fatigue. Elle échoue sur le contexte. Un scanner ne sait pas si un bouton « Supprimer » doit être visible par tout le monde ou par un administrateur, parce qu'il n'a pas la spécification fonctionnelle.
Nous utilisons ces outils en début de mission, pour dégrossir et gagner du temps sur le déjà connu. Le rapport qu'ils produisent est un point de départ de l'analyse, jamais son résultat.
Les cinq angles morts du scan automatique
La manipulation de la logique métier
Un paramètre de prix transmis par le client et accepté tel quel par le serveur avant le paiement, un code promotionnel cumulable à l'infini, une remise appliquée après contrôle du montant minimum : ces défauts ne déclenchent aucune signature. L'outil voit un champ numérique qui reçoit une valeur numérique et passe au suivant. Détecter ce type de faille suppose de comprendre ce que la fonctionnalité est censée produire, puis de détourner son usage pour obtenir un avantage indu.
Les défauts de contrôle d'accès
L'IDOR (Insecure Direct Object Reference) reste la faille la plus rentable pour un attaquant. Un utilisateur authentifié avec l'identifiant 123 appelle votre-site.com/facture/124 et reçoit la facture d'un autre client. La variante verticale consiste à atteindre une fonction d'administration depuis un compte standard, souvent parce que le contrôle de droits est fait dans l'interface et pas dans l'API.
Un scanner rate ces cas parce que la détection exige deux comptes de niveaux différents, une cartographie des ressources de chacun et une comparaison systématique des réponses. C'est un travail de méthode, pas de signature.
L'enchaînement de failles mineures
Un attaquant expérimenté combine. Une fuite de version dans une page d'erreur, un formulaire de contact qui accepte des pièces jointes mal filtrées, un répertoire d'upload accessible en écriture : chacune de ces faiblesses serait classée en criticité faible dans un rapport automatique. Mises bout à bout, elles donnent une exécution de code sur le serveur. Les outils traitent chaque constat isolément et ne construisent pas de scénario.
Les API et endpoints non référencés
Les applications modernes reposent sur des API que le site public n'expose pas dans ses liens. D'anciennes versions restent en service pour la compatibilité d'une application mobile, une route de test survit à une mise en production, un endpoint interne devient joignable après un changement de reverse proxy. Un scanner explore ce qu'il trouve en suivant les liens. Ce qui n'est lié à rien lui échappe, mais pas à celui qui analyse le trafic réseau de votre application mobile ou qui interroge les fichiers de configuration JavaScript.
La gestion des sessions et de l'authentification
Un outil vérifie qu'un cookie porte les attributs HttpOnly, Secure et SameSite. Il ne vérifie pas qu'une session est réellement invalidée côté serveur après déconnexion, qu'un jeton de réinitialisation de mot de passe expire, que le changement de mot de passe révoque les sessions ouvertes ailleurs, ou que le second facteur ne peut pas être contourné en rejouant une requête intermédiaire. Ces défauts alimentent la majorité des vols de compte.
La lecture d'un rapport de scan
Criticité théorique et exploitabilité réelle
Le score CVSS décrit une vulnérabilité dans l'absolu, pas dans votre système. Une faille notée 9.0 peut être inexploitable chez vous parce que le module concerné est désactivé ou que le composant n'est accessible que depuis un réseau interne. Une faille notée 4.0 sur un formulaire de connexion peut ouvrir la première marche d'une chaîne qui finit dans votre base clients.
La priorisation se fait sur l'exposition réelle, la valeur de la donnée atteinte et l'effort nécessaire à l'attaquant. Un tableau trié par CVSS décroissant occupe les équipes de développement sans réduire le risque le plus probable.
Les faux positifs
Les scanners produisent du bruit. Une réponse de serveur mal interprétée, une page d'erreur générique renvoyée en code 200, un paramètre reflété sans exécution : autant de signalements à qualifier avant de les transmettre aux développeurs. Chaque faux positif corrigé coûte du temps d'équipe et abîme la crédibilité de la démarche auprès de ceux qui font le travail. La qualification manuelle des résultats fait partie du test, elle n'est pas une étape optionnelle.
Le score global
Une note sur 100 ou une lettre de A à F agrège des critères de configuration. C'est un indicateur de suivi acceptable pour une direction générale, à condition de savoir ce qu'il mesure. Un site noté 95 peut porter une seule faille d'accès qui permet d'exporter l'intégralité des comptes clients. L'attaquant n'a besoin que d'un chemin, et votre moyenne ne l'intéresse pas.
Le seuil de l'audit professionnel
Les données sensibles et les flux financiers
Dès que la plateforme traite des données personnelles à grande échelle, des données de santé ou des transactions, l'autodiagnostic atteint sa limite. L'article 32 du RGPD impose des mesures techniques et organisationnelles adaptées au risque, et prévoit explicitement une procédure de test et d'évaluation régulière de leur efficacité. Un scan gratuit archivé dans un dossier partagé tient difficilement ce rôle devant une autorité de contrôle. Notre audit applicatif cible précisément les défauts de logique et de contrôle d'accès que les outils ignorent.
NIS 2, DORA et les exigences de preuve
Les entités essentielles et importantes au sens de NIS 2 doivent mesurer l'efficacité de leurs mesures de gestion des risques. Les entités financières sous DORA relèvent d'un régime de tests de résilience opérationnelle numérique, avec des tests avancés fondés sur la menace pour les plus significatives d'entre elles. Dans les deux cas, le régulateur attend un livrable produit par un tiers indépendant, avec une méthodologie traçable. Notre qualification PASSI répond à cette attente, y compris dans les réponses à appels d'offres où la preuve d'audit externe est devenue une condition d'accès. Un audit de conformité cyber permet d'articuler ces obligations plutôt que de les empiler.
Les refontes et les mises en production majeures
Le risque se concentre sur les périodes de changement. Migration de framework, refonte du parcours client, ajout d'un module de paiement, bascule vers une nouvelle API : chaque évolution peut réintroduire une régression sur un contrôle d'accès validé six mois plus tôt. Programmez le test avant la bascule, pas après le premier incident. Une analyse de risque cyber menée en amont oriente l'effort de test vers les fonctions qui portent réellement la valeur.
Ce qu'il faut retenir
- Un scan automatique couvre la configuration et les vulnérabilités publiées, pas votre logique métier.
- L'autorisation écrite conditionne tout test technique, y compris chez un prestataire qui héberge votre site.
- Les en-têtes HTTP, la configuration TLS et les fichiers exposés se vérifient en interne, sans outillage particulier.
- Le contrôle d'accès et l'enchaînement de failles mineures échappent structurellement à l'automatisation.
- Une note « A+ » sur un scanner public décrit une posture de surface.
- La qualification PASSI apporte l'indépendance et la traçabilité attendues par les régulateurs.
Questions fréquentes
Est-il dangereux d'utiliser des scanners de sécurité en ligne ?
Les scanners passifs, qui se contentent de lire des en-têtes et une configuration TLS, ne présentent aucun risque pour votre service. Les outils actifs, eux, envoient des requêtes malformées et remplissent des formulaires : ils peuvent ralentir la production, générer des milliers d'enregistrements parasites ou déclencher des envois d'e-mails vers vos clients. Lancez-les d'abord sur un environnement de préproduction représentatif, et prévenez vos équipes d'exploitation.
Pourquoi mon scanner indique-t-il que mon site est sûr alors que j'ai été piraté ?
Les scanners cherchent des signatures de vulnérabilités déjà cataloguées. Une compromission issue d'un mot de passe administrateur récupéré dans une fuite tierce, d'un défaut de contrôle d'accès sur une API ou d'un composant développé sur mesure ne correspond à aucune signature. L'outil a fait ce pour quoi il est conçu, sur un périmètre plus étroit que celui de l'attaquant.
Quelles sont les failles les plus fréquentes en 2026 ?
Le Top 10 de l'OWASP reste la référence de cadrage, avec le contrôle d'accès défaillant en tête. Sur le terrain, deux tendances dominent : les API insuffisamment protégées, souvent parce que les contrôles sont implémentés dans l'interface plutôt que côté serveur, et les erreurs de configuration des environnements cloud. Les attaques sur la chaîne d'approvisionnement logicielle, via une bibliothèque tierce compromise, progressent également.
Combien coûte un test d'intrusion applicatif ?
Le coût dépend du nombre de fonctionnalités à parcourir, du nombre de profils utilisateurs à comparer et de la présence d'API. Comptez de quelques jours à plusieurs semaines de charge. La bonne comparaison n'est pas avec le prix d'un outil gratuit, mais avec le coût d'une interruption d'activité, d'une notification de violation et de la remédiation dans l'urgence.
Un test d'intrusion garantit-il une sécurité totale ?
Non. Un test décrit votre niveau de résistance à un instant donné, sur un périmètre défini, avec le temps imparti à l'auditeur. Il permet de corriger ce qui est exploitable au moment de l'audit. Le code évolue, les dépendances aussi, et les techniques d'attaque également : le test se renouvelle au rythme des changements de votre application.
Pour aller plus loin
Commencez par ce qui ne coûte que du temps. Vérifiez vos en-têtes et votre configuration TLS avec Mozilla Observatory ou SSL Labs, testez l'accès à .git, .env et aux consoles d'administration depuis une connexion extérieure, listez les comptes actifs sur vos environnements de recette. Inscrivez la mise à jour des composants dans un cycle de maintenance daté, avec un responsable nommé. Formez vos développeurs aux failles de contrôle d'accès, puisqu'elles sortent rarement d'un outil et toujours d'une revue de code ou d'un test manuel.
Ensuite, décidez du périmètre qui justifie un regard externe : les parcours qui manipulent de l'argent, les données personnelles et les droits d'administration. Nous ne vendons pas d'outils et n'éditons pas de logiciels, notre évaluation reste indépendante de ce que vous avez déjà déployé. Si vous voulez cadrer un test d'intrusion sur votre application, contactez-nous.