Lors d’un audit applicatif conduit sur le SI d’un groupe de distribution (30 sites, 18 applications interconnectées), Mink a identifié une couche d’API internes qui n’exigeait aucun jeton d’authentification. Aucune des 18 applications ne vérifiait l’identité de celle qui l’appelait. Le score CVSS de ce finding : 10,0 sur 10.
Ce type de faille n’est pas une exception. C’est le schéma le plus fréquent dans les architectures sur-mesure vieillissantes : des API internes traitées comme « sûres par définition » parce qu’elles ne sont pas exposées publiquement. L’OWASP API Top 10 existe précisément pour nommer ce que cette hypothèse coûte.
Pourquoi les API métier sont un angle mort de la sécurité applicative
La sécurité applicative classique se concentre sur le périmètre exposé : le front web, les formulaires de connexion, les endpoints publics. Les API internes, celles qui relient un ERP à un portail commercial, un back-office RH à un système de provisioning, ou un CRM à un entrepôt de données, bénéficient d’une forme d’immunité implicite. Elles sont derrière le VPN, derrière le pare-feu, « dans le réseau ».
Le problème : cette immunité est présumée, rarement vérifiée. Et dans les architectures sur-mesure construites par couches successives sur 5 à 10 ans, les API internes concentrent exactement ce que les attaquants cherchent : données financières consolidées, identités, droits d’accès, flux vers les ERP.
94 % des applications web testées présentent des failles de broken access control (OWASP, 2021). Sur les API internes non exposées publiquement, ce taux est structurellement plus élevé, parce que ces API ont été conçues avec l’hypothèse que leur appelant était de confiance.
L’OWASP API Top 10 : trois vecteurs qui frappent systématiquement les architectures métier sur-mesure
L’OWASP publie depuis 2019 un référentiel spécifique aux API, distinct du Top 10 web classique. Sa version 2023 liste dix catégories de risques. Sur les applicatifs métier sur-mesure, trois reviennent dans presque tous les audits.
API1:2023 – Broken Object Level Authorization (BOLA)
C’est le vecteur numéro 1. Un utilisateur authentifié peut accéder ou modifier des objets qui ne lui appartiennent pas en manipulant un identifiant dans la requête. Sur un applicatif métier : changer GET /api/contrats/1042 en GET /api/contrats/1043 pour accéder au contrat d’un autre client, d’une autre concession, d’un autre centre de profit.
Dans les API métier sur-mesure, ce type de contrôle est souvent absent parce qu’il n’a pas été spécifié. Le développeur a codé l’authentification (qui peut appeler l’API), pas l’autorisation au niveau objet (qui peut lire quoi). Les deux problèmes sont distincts, et le second est le plus dangereux.
API2:2023 – Broken Authentication
Jetons JWT avec une clé de signature triviale (de type abcdefg, réutilisée à travers 12 applications), vérification d’identité commentée ou désactivée, tokens inter-services sans expiration : ces défauts permettent de forger une identité valide sans accès légitime au système.
Sur une architecture où 8 ou 10 applications se font mutuellement confiance via des jetons, une seule clé compromise ouvre l’ensemble du parc. Le rayon d’explosion d’une clé partagée est proportionnel au nombre d’applications qui la consomment.
API3:2023 – Broken Object Property Level Authorization (mass assignment)
Les API REST modernes acceptent souvent des objets JSON en entrée. Si l’endpoint ne filtre pas explicitement les propriétés autorisées, un appelant peut injecter des champs arbitraires : role: admin, validated: true, salary: 0. Sur des frameworks PHP sans configuration stricte des accesseurs de masse, ce vecteur est exploitable sans sophistication particulière.
Dans les applicatifs sur-mesure construits rapidement, les filtres d’entrée sont souvent absents, soit parce que la donnée venait initialement d’un formulaire interne « de confiance », soit parce que l’API a été réutilisée sans être revue.
Ce que ces failles produisent concrètement dans une architecture métier interconnectée
L’enjeu n’est pas théorique. Sur un SI métier où ERP, portail commercial et back-office partagent des API internes, trois scénarios d’impact se construisent à partir de ces vecteurs.
Altération de données financières consolidées. Une injection SQL dans les requêtes d’une API financière, combinée à l’absence de contrôle d’intégrité côté base, permet de modifier des balances comptables sans laisser de trace. Les décisions de gestion qui s’appuient sur ces données sont prises sur des chiffres faux.
Usurpation d’identité inter-services. Un jeton forgeable sur une API interne permet à un attaquant de se faire passer pour n’importe quelle application du parc et d’accéder aux bases de données, aux systèmes RH, aux flux vers l’Active Directory.
Exfiltration silencieuse de données personnelles. Une API qui expose des données nominatives sans authentification, noms, salaires, numéros de sécurité sociale dans un contexte RH, peut être énumérée sans aucun compte valide. Le manquement RGPD est constitué dès la conception, pas au moment de l’incident.
Dans tous ces scénarios, le point de départ est le même : l’API interne n’a pas besoin d’être sécurisée comme une API publique. L’OWASP API Top 10 démontre le contraire.
Ce que ça change dans la façon de concevoir et d’auditer les API métier
À la conception
Trois principes structurants, souvent absents des cahiers des charges :
Auth par défaut, pas par exception. Toute API interne doit exiger un jeton valide, même si son appelant est « une autre application du même parc ». Le modèle Zero Trust s’applique au SI interne comme au périmètre externe.
Un jeton par application, pas une clé partagée. Quand une clé de signature est commune à 12 applications, la compromission d’une seule ouvre les 11 autres. Le coût d’une clé applicative propre est négligeable ; le coût d’une rotation d’urgence après incident ne l’est pas.
Validation stricte des entrées et des sorties. Chaque endpoint doit définir explicitement ce qu’il accepte et ce qu’il retourne. Un schéma OpenAPI bien défini n’est pas de la documentation : c’est la première ligne de défense contre le mass assignment et les injections.
À l’audit
Un audit de sécurité API métier ne se résume pas à un scan automatisé. Les outils SAST détectent des patterns connus ; ils ne reconstituent pas les chaînes d’exploitation qui traversent plusieurs services. Un audit sérieux couvre :
- La vérification des mécanismes d’authentification inter-services (jeton, signature, expiration)
- Le contrôle d’accès au niveau objet pour les endpoints exposant des données métier
- La revue des dépendances tierces via SCA (
composer audit,npm audit) pour les CVE connues - Le scoring CVSS v3.1 finding par finding, pour prioriser la remédiation selon l’impact réel
Sur 486 CVE identifiées dans les dépendances d’un parc PHP de 18 applications, une seule bibliothèque, phpspreadsheet, présente dans 14 applications, concentrait un vecteur RCE/SSRF exploitable sans authentification préalable.
Les questions à se poser maintenant
Si vous gérez un SI métier avec des applications interconnectées, trois questions permettent de calibrer l’exposition réelle.
Vos API internes exigent-elles une authentification différente selon l’appelant ? Si toutes les applications du parc présentent le même jeton, ou aucun, la surface d’attaque est ouverte.
Avez-vous une liste exhaustive de vos endpoints internes et de ce qu’ils exposent ? Les architectures sur-mesure accumulant des versions parallèles (V1, V2, V3 coexistant en production) ont systématiquement des endpoints oubliés, non documentés, et non protégés.
Quand avez-vous audité vos dépendances pour la dernière fois ? Un composer audit ou npm audit prend cinq minutes. Sur un parc de plus de dix applications avec des dépendances non mises à jour depuis 18 mois, le résultat est rarement inférieur à une centaine de CVE.
Ce que Mink fait différemment
Un audit applicatif conduit par Mink couvre le SI entier, pas application par application. Les scénarios d’exploitation les plus graves naissent de la combinaison de failles dispersées : une couche RPC non authentifiée, plus un jeton forgeable, plus une injection SQL financière. Les analyser séparément, c’est manquer l’essentiel.
Notre méthode : analyse statique exhaustive (lecture seule, zéro impact production), scoring CVSS v3.1 par finding, scénarios d’attaque documentés, et un plan de remédiation séquencé par priorité réelle, pas par facilité technique.
Vous souhaitez cartographier l’exposition de vos API métier ? Contactez-nous pour un cadrage d’audit.
