Les interfaces applicatives sont devenues la surface d’attaque principale de beaucoup d’organisations, et la moins testée. Elles échappent souvent aux audits parce qu’elles n’ont pas d’interface visible.
Voici les défauts que nous retrouvons le plus souvent.
1. Le contrôle d’accès au niveau de l’objet
Le défaut numéro un, et de loin. L’application vérifie que l’utilisateur est authentifié, mais pas qu’il a le droit d’accéder à cet objet précis.
Concrètement : une requête sur un identifiant de commande retourne la commande d’un autre client si on modifie le numéro. L’authentification fonctionne, l’autorisation non.
C’est trivial à exploiter, souvent invisible dans les journaux applicatifs, et cela figure en tête de la classification OWASP API Security Top 10.
2. L’exposition excessive de données
L’interface retourne l’objet complet issu de la base, et l’application cliente n’en affiche qu’une partie. Le reste — identifiants internes, données personnelles, jetons — circule quand même et reste lisible.
Le principe correct est de construire explicitement la réponse, champ par champ, plutôt que de sérialiser un objet entier.
3. L’absence de limitation de débit
Sans limite, une interface permet l’énumération massive : parcourir tous les identifiants, tester des combinaisons d’authentification, extraire une base entière requête par requête.
Une limitation par utilisateur et par adresse, assortie d’une alerte au-delà d’un seuil, ferme cette voie — et rejoint la logique de détection d’anomalies.
4. Les interfaces oubliées
Versions antérieures laissées actives, environnements de recette accessibles depuis Internet, points d’entrée de test jamais retirés.
Une version ancienne encore en ligne conserve les vulnérabilités corrigées ailleurs. C’est un cas particulier du défaut de cloisonnement entre test et production.
La contre-mesure est d’abord un inventaire : on ne sécurise pas une interface dont on ignore l’existence.
5. Les secrets dans les clients
Une clé d’interface intégrée à une application mobile ou à un code exécuté dans le navigateur n’est pas un secret. Elle est lisible par quiconque examine le code.
Ce qui suppose que toute autorisation reposant sur cette clé doit être considérée comme publique, et que les opérations sensibles doivent être contrôlées côté serveur.
6. Les journaux insuffisants
Beaucoup d’interfaces ne journalisent que les erreurs techniques. Ni l’identité de l’appelant, ni l’objet accédé, ni le volume retourné.
Sans ces éléments, une extraction massive de données est indistinguable d’un usage normal, et l’investigation après incident devient impossible — voir ce qu’il faut collecter.
7. L’authentification entre services négligée
Les appels entre composants internes reposent souvent sur la seule confiance réseau : « ce service est dans le même segment, donc il est légitime ».
C’est précisément l’hypothèse que remet en cause le modèle de vérification systématique. Un composant compromis appelle alors librement tous les autres.
Comment tester
Un test d’intrusion applicatif classique couvre mal les interfaces si l’auditeur ne dispose pas de leur description. Fournir la spécification et des comptes de test de différents niveaux de droits change complètement le résultat.
Le test le plus rentable : prendre deux comptes utilisateurs distincts et tenter d’accéder aux objets de l’un avec le jeton de l’autre. Ce contrôle simple révèle le défaut n° 1, qui est aussi le plus répandu.
Ce que demandent les référentiels
ISO/IEC 27002:2022 traite le sujet par la mesure 8.26 — exigences de sécurité des applications — et 8.28 sur le codage sécurisé, l’une des nouveautés de la révision 2022.
Côté données personnelles, une interface qui expose plus que nécessaire contrevient au principe de minimisation du RGPD, indépendamment de toute intrusion.
Sources
- OWASP API Security Top 10
- OWASP Web Security Testing Guide
- ISO/IEC 27002:2022, mesures 8.26 et 8.28
- Règlement (UE) 2016/679 (RGPD), article 5.1 c) — minimisation
Aller plus loin
Ces tests font partie de nos missions de sécurité offensive, et l’inventaire des interfaces exposées relève de l’audit 360.