Un test d’intrusion applicatif ne se limite pas à passer un scanner sur une URL. L’essentiel des vulnérabilités réellement exploitables dans les applications métier concerne le contrôle d’accès et la logique fonctionnelle : accéder aux données d’un autre client, franchir une étape d’un processus, modifier un paramètre qui n’aurait pas dû l’être.
Un scan automatisé seul ne couvre pas fiablement ces défauts : leur analyse nécessite de comprendre les rôles, les parcours et les règles métier de l’application.
Applicatif ou externe : comment choisir
Le test externe travaille en largeur sur l’ensemble de votre exposition Internet et répond à « par où peut-on entrer ». Il touche aux applications rencontrées, mais en surface.
Le test applicatif travaille en profondeur sur une application désignée et répond à « cette application-ci peut-elle être détournée ». Il suppose des comptes de test, du temps sur les parcours fonctionnels, et l’exploration de ce qui ne se voit pas depuis l’extérieur.
Les deux prestations sont complémentaires et se commandent séparément.
Approche recommandée
L’approche en boîte grise, avec un compte de test par rôle applicatif, donne un meilleur retour sur investissement : elle permet de couvrir les fonctionnalités réservées et de tester le cloisonnement entre utilisateurs, ce qui est impossible en boîte noire dans le temps imparti.
La documentation fonctionnelle et les spécifications d’API, lorsqu’elles existent, sont utilisées pour couvrir l’ensemble des points d’entrée — y compris ceux qui ne sont référencés par aucun lien.
Domaines couverts
- Contrôle d’accès — accès horizontal et vertical, manipulation de références directes à des objets, cloisonnement entre organisations ou clients dans les applications multi-locataires.
- Authentification et sessions — robustesse du mécanisme, parcours de réinitialisation de mot de passe, second facteur et possibilités de contournement, cycle de vie des jetons, validation de leur signature, effet réel de la déconnexion.
- Logique métier — contournement d’étapes, manipulation de montants ou de quantités, conditions de course sur les opérations sensibles, réexécution de requêtes.
- Injections — SQL et NoSQL, commandes système, moteurs de gabarits côté serveur, désérialisation de données contrôlées par l’utilisateur.
- Traitement des entrées et des fichiers — téléversements, injection de code côté client, redirections non contrôlées, requêtes forgées côté serveur permettant d’atteindre des ressources internes.
- API — points d’entrée exposés mais non documentés, versions anciennes laissées actives, limitation de débit, exposition excessive de champs dans les réponses, écarts de contrôle entre l’interface Web et l’API sous-jacente.
- Configuration — en-têtes de sécurité, gestion des erreurs, politique de partage entre origines, secrets présents dans le code livré au navigateur.
La couverture s’appuie sur le guide de test applicatif de l’OWASP dans sa version stable, et sur la liste OWASP des risques de sécurité des API, afin qu’aucune catégorie ne soit omise. Ces référentiels servent de grille de couverture, pas de liste de contrôle à cocher.
Contraintes de production
Lorsque le test porte sur un environnement de production, les modalités sont définies au préalable : plages horaires, volume de requêtes, comptes dédiés, données de test identifiables, actions interdites, procédure d’arrêt immédiat.
Résultat
Chaque vulnérabilité est documentée avec la requête permettant de la reproduire, son impact métier, sa criticité et une recommandation de correction adaptée à la technologie utilisée — utilisable directement par vos développeurs.