« Notre application est sécurisée. » Cette phrase, la plupart des éditeurs la prononcent de bonne foi. Le problème, c'est qu'elle repose souvent sur une checklist cochée par ceux-là mêmes qui ont écrit le code. Or la sécurité ne se déclare pas : elle se teste, avec une posture offensive.
La différence entre vérifier et attaquer
Une revue de sécurité classique se demande « est-ce que ça a l'air correct ? ». Un audit d'intrusion se demande « comment j'attaque ça ? ». C'est une différence de posture radicale. Le second écrit et lance de vrais tests d'attaque, reproduit les exploits, et ne se contente pas de lire le code.
Le risque n°1 : le contrôle d'accès
Dans une application multi-tenant (plusieurs clients sur la même plateforme), la faille la plus grave et la plus fréquente est l'IDOR : accéder aux données d'un autre client en manipulant un identifiant. On le teste concrètement — prendre le jeton d'un client A et tenter d'atteindre une ressource du client B, sur chaque point d'entrée. On teste aussi le franchissement de rôles (un utilisateur qui atteint une action réservée), et le rejeu ou l'expiration des jetons publics.
Les autres vecteurs prioritaires
Les injections (SQL, mais aussi injection de prompt quand des données utilisateur atteignent un modèle d'IA), le chiffrement (une clé réutilisée, un secret qui fuit dans un message d'erreur), l'authentification (rotation des jetons, force brute sur le login), et l'intégrité des webhooks. Chaque finding est classé par gravité, avec un scénario d'exploitation reproduit et un correctif.
La règle d'or : l'indépendance
Un audit n'a de valeur que s'il est mené par un regard neuf, jamais par l'auteur du code. On ne peut pas être juge et partie. C'est pour cela que l'audit adversarial doit se faire en contexte frais, avec le mandat explicite de casser l'application — pas de la rassurer.
À quelle fréquence
Une passe fondatrice sur toute la surface d'attaque, puis un audit du périmètre modifié à chaque évolution sensible (authentification, isolation des données, endpoints publics, paiements), puis un re-balayage périodique. La sécurité n'est pas un jalon, c'est un processus.
Chez Diwai, cette exigence fait partie de la méthode, pas des options. Pour un décideur, c'est la différence entre « on nous a dit que c'était sécurisé » et « on l'a prouvé ».
