Tester une application web avant sa mise en production
Une application se met en ligne avec ses fonctionnalités validées et sa sécurité supposée. Le test d'intrusion applicatif transforme cette supposition en constat, avant que ce ne soit un tiers qui s'en charge.
Ce qu'un scanner ne trouvera jamais
L'analyse automatisée couvre l'essentiel des défauts techniques connus : bibliothèques obsolètes, en-têtes absents, injections classiques. C'est utile, c'est rapide, et il faut le faire. Mais un scanner ne connaît pas votre métier.
Or les défauts qui coûtent le plus cher sont précisément ceux qui tiennent à votre logique : un identifiant de commande qu'on peut incrémenter pour lire le dossier du client suivant, un rôle qui ne vérifie l'autorisation qu'à l'affichage et non à l'action, un tarif recalculé côté navigateur, une étape de validation qu'on peut sauter. Aucune de ces failles n'a de signature ; elles se trouvent en comprenant ce que l'application est censée faire.
À cela s'ajoute la surface que le navigateur ne montre pas : les API. Elles portent souvent des contrôles moins stricts que l'interface qui les appelle, parce qu'on suppose que personne ne les appellera directement. C'est une supposition qui se vérifie mal.
- Accès aux données d'un autre client par simple changement d'identifiant
- Contrôle d'autorisation présent à l'affichage, absent à l'action
- API moins protégée que l'interface qui la consomme
- Règle métier contournable en sautant une étape
- Correctifs livrés sans vérification qu'ils tiennent
Cinq étapes, dont une que l'on oublie souvent
Comment nous procédons
Le test se fait de préférence sur un environnement de recette fidèle à la production, avec des jeux de données représentatifs mais sans données réelles de clients.
Cadrage et accès
Périmètre, environnement, rôles à tester et règles d'engagement. Nous demandons des comptes de chaque niveau de privilège : c'est ce qui permet de vérifier qu'un utilisateur simple ne peut pas faire ce qu'un administrateur fait.
Cartographie fonctionnelle
Parcours de l'application comme un utilisateur, puis relevé des points d'entrée, des API sous-jacentes et des règles métier qui les gouvernent. Cette étape conditionne tout le reste : on ne teste bien que ce qu'on a compris.
Exploitation manuelle
Recherche des défauts d'autorisation, de logique métier, d'authentification et de session, des injections et des dépendances vulnérables. Chaque trouvaille est exploitée jusqu'à démontrer son impact réel, jamais laissée à l'état de soupçon.
Restitution priorisée
Rapport à deux lectures : ce qu'un attaquant pouvait atteindre et ce qu'il faut décider, puis le détail technique avec preuve reproductible et correction proposée. Le tri suit le risque dans votre contexte, pas un score brut.
Contre-test
Après correction, nous rejouons les scénarios retenus pour vérifier que les correctifs tiennent et n'ont pas déplacé le problème ailleurs.
Plusieurs expertises, un seul interlocuteur
Le test révèle, la revue de code remonte à la racine, la formation évite la récidive.
- Rapport priorisé selon le risque réel
- Preuve d'exploitation reproductible par vos équipes
- Correction proposée pour chaque constat
- Restitution technique et exécutive
- Contre-test de validation des correctifs
Questions fréquentes
Votre application part en ligne la semaine prochaine ?
Décrivez-nous son périmètre : nous vous dirons ce qu'un test peut couvrir d'ici là.