Aucun analyseur ne trouve tout : contrôle d'accès défaillant, logique métier et la limite de l'analyse automatique
Pourquoi la catégorie de risque classée première dans l'OWASP Top 10:2025 est aussi celle qu'un analyseur voit le moins bien, où s'arrête exactement la recherche de schémas, et quelle vérification prend en charge ce qui n'a pas de schéma : le test d'intrusion comme pendant de l'analyse continue.
Ce qu'un analyseur voit
Un analyseur de code travaille avec des schémas et des listes connues. Un mot de passe dans le code source a une forme reconnaissable. Une bibliothèque à faille connue figure dans une base de données. Une entrée qui part sans contrôle dans une requête de base de données suit une structure identifiable, tout comme un appel qui assemble des commandes système à partir d'entrées utilisateur. Pour ces catégories, une analyse à chaque commit est le bon outil, parce qu'elle les trouve dès qu'elles apparaissent et, correctement qualifiées, les documente avec une date.
Les contrôles d'accès manquants en font partie aussi, mais sous une forme étroite seulement : un point d'accès joignable sans aucune vérification d'autorisation saute aux yeux. C'est la part du contrôle d'accès défaillant que les schémas saisissent. Ce n'est pas celle qui cause le plus de dégâts en pratique.
Pourquoi la première place du Top 10 reste en partie invisible
Le contrôle d'accès défaillant occupe la première place de l'édition 2025 de l'OWASP Top 10. La catégorie va bien au-delà d'un point d'accès non protégé. Elle couvre le cas où un contrôle existe et reste pourtant faux : l'utilisateur est vérifié, mais pas le fait que l'enregistrement demandé lui appartient. Le collaborateur peut voir des factures, mais seulement celles de son site, et le logiciel ne demande jamais le site. Le client peut modifier son contrat, mais pas le prix, et le champ est masqué dans le formulaire au lieu d'être verrouillé côté serveur.
Pour chacun de ces cas, il existe du code qui effectue un contrôle d'accès. L'analyseur voit le contrôle et s'en satisfait. Que le contrôle pose la bonne question n'est écrit dans aucun schéma, mais dans le modèle métier. C'est pourquoi notre page consacrée à la sécurité du code indique que les erreurs de logique métier échappent à l'analyse automatique, et pourquoi nous ne traitons pas cela comme des petits caractères.
La seconde limite : la conception
À côté de la logique métier, il existe une seconde classe d'erreurs sans schéma : les décisions prises avant le code. Un composant doit-il seulement être joignable directement depuis le réseau. Deux services doivent-ils partager le même utilisateur de base de données. Un jeton prévu pour une heure n'expire-t-il en réalité jamais, parce que personne ne l'a spécifié. Dans tous ces cas, le code source est sans faute aux yeux de l'analyseur. La faute est dans ce que le code source met en œuvre.
À cela s'ajoute ce que tout analyseur fait à l'inverse : il signale aussi des résultats qui ne sont pas exploitables dans le cas concret. Une personne qui qualifie chaque résultat tient ces faux positifs hors du rapport. Elle ne rend pas pour autant l'analyseur voyant pour ce qui n'a pas de schéma.
Ce que le test d'intrusion prend en charge
Un test d'intrusion part de l'extérieur. Il prend le système en fonctionnement dans son ensemble, réseau, configuration, autorisations et personnes compris, et tente de le franchir. Un testeur connecté comme utilisateur A qui veut voir les factures de l'utilisateur B essaie, tout simplement. Il n'a pas besoin de schéma, il a besoin de la question métier. C'est exactement pour cela qu'un bon test trouve les erreurs devant lesquelles l'analyse passe, et exactement pour cela qu'il ne les trouve que le jour du test.
Le test lui-même, nous ne nous l'attribuons pas, et pour une raison : qui exploite l'analyse ne devrait pas être aussi celui qui certifie que rien ne lui a échappé. Notre rôle se situe avant et après le test. Avant : déterminer si un test est seulement le bon instrument en ce moment, et vous donner les critères pour comparer les prestataires. Après : transformer les résultats du rapport en mesures closes. Plus de détails sur notre page consacrée au test d'intrusion.
Comment les deux se combinent
La répartition des rôles est simple une fois énoncée. L'analyse maintient en continu hors du code les catégories d'erreurs qui ont un schéma et le documente avec une date : secrets, dépendances vulnérables, schémas non sécurisés, points d'accès non protégés. Le test vérifie périodiquement si les contrôles existants posent la bonne question et si la conception tient. Qui se contente de tester a une année sans vérification entre deux dates. Qui se contente d'analyser n'a la première place du Top 10 qu'à moitié en vue.
Pour la preuve, cela signifie : un auditeur qui veut voir un test d'intrusion n'accepte pas un rapport d'analyse à la place. Et un auditeur qui veut voir la gestion des vulnérabilités lors du développement et de la maintenance au titre de l'article 30 du BSIG n'accepte pas un test annuel comme preuve du processus entre les deux.
Questions fréquentes
L'analyse CAVRIX trouve-t-elle le contrôle d'accès défaillant ?
La part qui a un schéma, oui : points d'accès sans aucune vérification d'autorisation et constructions non sécurisées connues. La part sans schéma, à savoir si un contrôle existant pose la bonne question métier, aucun analyseur ne la trouve. Le test d'intrusion est l'outil pour cela.
Pourquoi énoncez-vous cette limite aussi clairement ?
Parce qu'une preuve qui laisserait croire que l'analyse couvre tout serait fausse en audit ou après un incident. Nous préférons écrire à l'avance ce que l'analyse ne peut pas faire plutôt qu'expliquer ensuite pourquoi quelque chose est passé.
CAVRIX propose-t-il des tests d'intrusion ?
Non. Nous vous disons si vous en avez besoin, à quoi veiller dans le choix, et prenons en charge ce qui vient après le rapport. L'analyse continue est notre part ; le test, celle d'un prestataire spécialisé.