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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Ces tests font partie de nos missions de sécurité offensive, et l’inventaire des interfaces exposées relève de l’audit 360.
Un recrutement cyber raté coûte davantage qu’un poste vacant : le temps d’encadrement consommé, la mission dégradée chez un client, et le délai avant de recommencer. Les causes se répètent. ...
1-3 Rue d’Enghien
75010, Paris
France
Recevez les actualités du site Cyberdian.
