Sommaire
D’après l’OWASP Top 10 2025, les failles les plus répandues sont le contrôle d’accès défaillant, les erreurs de configuration et les failles de la chaîne de dépendances. Dans un outil métier, cela donne des données clients visibles par d’autres utilisateurs, des clés exposées ou des bibliothèques obsolètes. Un audit express à 589€HT permet de les repérer.
La plupart des failles qui touchent les applications web ne sont pas sophistiquées. Ce sont des oublis : un contrôle de droits absent, une clé laissée dans le code, une bibliothèque jamais mise à jour. Elles sont d’autant plus fréquentes que l’application a été développée vite, sans revue, ou générée par un outil d’IA. Voici les plus répandues selon le référentiel de l’OWASP, ce qu’elles donnent concrètement dans un outil métier et comment les corriger.
Le référentiel : l’OWASP Top 10
L’OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui publie le Top 10 des risques de sécurité des applications web. La version 2025, consultée le 27 octobre 2026, classe ces dix catégories :
- A01 Contrôle d’accès défaillant
- A02 Erreurs de configuration de sécurité
- A03 Défaillances de la chaîne d’approvisionnement logicielle
- A04 Défaillances cryptographiques
- A05 Injection
- A06 Conception non sécurisée
- A07 Défaillances d’authentification
- A08 Défaillances d’intégrité des logiciels ou des données
- A09 Défaillances de journalisation et d’alerte
- A10 Mauvaise gestion des conditions exceptionnelles
D’après l’introduction du référentiel, huit catégories sont issues de données de tests portant sur plus de 2,8 millions d’applications et deux d’une enquête auprès des professionnels de la sécurité. C’est la référence que j’utilise pour mes audits et mes revues de code.
Ce que donnent ces failles dans un outil métier
| Catégorie OWASP | Exemple concret dans un outil métier | Conséquence | Correction |
|---|---|---|---|
| A01 Contrôle d’accès | En changeant le numéro dans l’adresse d’une commande, un client voit celle d’un autre client | Fuite de données, violation à notifier | Droits vérifiés côté serveur et dans la base, pour chaque requête |
| A02 Configuration | Espace de stockage des factures accessible publiquement, mode débogage actif en production | Documents exposés, informations techniques révélées | Revue de configuration, réglages restrictifs par défaut |
| A03 Chaîne d’approvisionnement | Bibliothèques jamais mises à jour depuis la livraison, dont certaines ont des vulnérabilités connues | Porte d’entrée connue des attaquants | Inventaire des dépendances, mises à jour régulières, alertes automatiques |
| A04 Cryptographie et secrets | Clé secrète d’un service (paiement, base de données, IA) présente dans le code envoyé au navigateur | Accès complet au service, facture d’usage détournée | Clés uniquement côté serveur, rotation immédiate si exposée |
| A05 Injection | Champ de recherche qui construit une requête à partir du texte saisi | Lecture ou modification de la base | Requêtes paramétrées, validation des entrées |
| A07 Authentification | Pas de limite au nombre d’essais de mot de passe, pas de double authentification pour les administrateurs | Comptes devinés ou réutilisés après une fuite ailleurs | Limitation des tentatives, double authentification |
| A09 Journalisation | Aucune trace des connexions ni des exports de données | Impossible de savoir ce qui a fuité après un incident | Journal des actions sensibles, conservé et consultable |
| A10 Conditions exceptionnelles | Message d’erreur qui affiche la requête et la structure de la base | Aide précieuse pour un attaquant | Messages génériques à l’écran, détail dans les journaux |
Ces exemples sont des situations types, pas des cas de clients. Le contrôle d’accès est traité en détail dans gérer les droits d’accès par rôle, l’authentification dans double authentification et sécurité des comptes.
Le cas des applications générées rapidement
Les outils d’IA et de no-code permettent de produire une application qui fonctionne en quelques jours. Le risque est qu’elle fonctionne pour un utilisateur honnête, sans résister à un utilisateur curieux. Deux points méritent une attention particulière.
Les droits vérifiés seulement dans le navigateur. Si l’interface masque les données d’un autre client mais que le serveur les renvoie quand même, n’importe qui peut les récupérer avec les outils de développement de son navigateur.
La sécurité de la base désactivée. Avec Supabase, très utilisé par ces outils, la documentation officielle (consultée le 27 octobre 2026) précise que la clé publique peut figurer dans le navigateur à condition que la sécurité au niveau des lignes (Row Level Security) soit activée sur chaque table avant la mise en ligne et que la clé secrète, qui contourne toutes ces règles, ne doit jamais se trouver dans un navigateur, une application distribuée ou un dépôt de code. Une table oubliée suffit à exposer ses données.
Si votre application a été construite ainsi, la page projet commencé avec l’IA explique comment je la reprends, après audit.
Quand ce n’est pas une priorité
Je le dis franchement : un outil interne sans données personnelles ni financières, utilisé par trois personnes sur un réseau maîtrisé, n’a pas besoin du même niveau de vérification qu’un portail client ouvert sur Internet. L’effort de sécurité se proportionne aux données exposées et au nombre d’utilisateurs. En revanche, dès qu’une application est accessible depuis Internet et stocke des données de clients ou de salariés, les trois premières catégories de l’OWASP ne sont pas optionnelles.
Par où commencer
- Faites le test simple : avec un compte utilisateur ordinaire, modifiez l’identifiant dans l’adresse d’une fiche. Si vous voyez une fiche qui n’est pas la vôtre, la priorité est claire.
- Vérifiez les mises à jour : demandez à votre prestataire la date de la dernière mise à jour des dépendances.
- Faites auditer l’application : l’audit technique existe en version express (589€HT, quelques jours) pour un premier état des lieux, ou complète (1 990€HT, 5 à 7 jours) avec un plan d’action priorisé et chiffré. Le contenu de l’audit est détaillé dans audit de sécurité d’une application web.
- Corrigez par ordre de gravité, puis maintenez : mises à jour, revue des droits, contrôle de chaque nouvelle fonction.
Si l’audit conclut qu’une reconstruction est plus raisonnable qu’une correction, l’estimateur donne une première fourchette pour une application métier.
Questions fréquentes
Comment savoir si mon application présente ces failles ?
Certaines se repèrent vite : connectez-vous avec un compte simple et essayez de modifier l’identifiant dans l’adresse d’une fiche. Pour le reste (dépendances, configuration, clés, droits côté serveur), il faut examiner le code et l’hébergement. C’est l’objet de l’audit, express à 589€HT ou complet à 1 990€HT.
Les applications créées avec un outil d’IA sont-elles plus exposées ?
Elles ne sont pas condamnées à l’être, mais elles sont souvent générées pour fonctionner en démonstration plutôt que pour résister à un utilisateur malveillant. Les droits vérifiés uniquement dans le navigateur et la sécurité de la base désactivée font partie des points à contrôler en priorité.
Un hébergeur sérieux ne protège-t-il pas contre ces failles ?
Il protège l’infrastructure : serveurs, réseau, disponibilité. Il ne corrige pas une application qui renvoie les données d’un client à un autre, ni une clé secrète publiée dans le code. La sécurité de l’application reste à la charge de celui qui la développe et l’exploite.
Faut-il tout corriger d’un coup ?
Non. On corrige d’abord ce qui expose des données ou permet de prendre le contrôle (droits, clés, injections), puis on planifie le reste. Un plan d’action priorisé évite de bloquer l’activité pendant des semaines.