Les API dans la chaîne d'approvisionnement : pourquoi la sécurité des interfaces devient une question de preuve
NIS2 intègre la chaîne d'approvisionnement à l'analyse des risques, et les API en sont les liaisons discrètes. Pourquoi les défauts d'autorisation constituent la principale faiblesse des API, et pourquoi on ne sécurise que ce qui est proprement documenté.
Un logiciel est rarement un monolithe aujourd’hui. Composants, services partenaires et locataires communiquent par des interfaces, et ces API sont les liaisons discrètes de la chaîne d’approvisionnement. NIS2 exige expressément la sécurité de la chaîne d’approvisionnement dans l’analyse des risques. Une question longtemps jugée purement technique passe ainsi au premier plan : quel est le niveau de sécurité de ses propres interfaces, et peut-on le démontrer ?
L’interface est la surface d’attaque
Les faiblesses d’API les plus fréquentes ne sont pas des exploits sophistiqués, mais des défauts d’autorisation. Dans l’OWASP API Security Top 10, la Broken Object Level Authorization occupe la première place : une API livre des données sans vérifier correctement si le compte demandeur a le droit de les voir. Il suffit alors de modifier l’identifiant d’un objet dans la requête pour récupérer les données d’un autre. Trois points de contrôle déterminent la robustesse en pratique :
- Autorisation par objet : chaque requête vérifie si l’appelant peut consulter ou modifier cet objet précis, et pas seulement s’il est connecté.
- Authentification : des jetons de courte durée, liés et révocables, plutôt que des clés universelles à longue durée de vie.
- Limitation du débit : limites de requêtes et quotas empêchent qu’une interface devienne un point d’exfiltration de données ou un vecteur de surcharge.
Ce qui n’est pas documenté ne peut être sécurisé
De nombreux incidents ne proviennent pas d’interfaces connues, mais d’interfaces oubliées : des API fantômes jamais inscrites à l’inventaire, des API abandonnées restées ouvertes après un changement de version. Sans inventaire complet et à jour, toute défense reste lacunaire. Une description OpenAPI bien tenue est ici davantage qu’un confort pour les développeurs : c’est le contrat au regard duquel les autorisations, les versions et le comportement attendu peuvent tout simplement être vérifiés. Un portail développeur dédié, qui conserve ces descriptions de manière versionnée et par locataire, transforme un savoir dispersé en un registre traçable.
La sécurité comme propriété démontrable
Lorsque l’autorité de contrôle pose la question, il ne suffit pas d’affirmer que les API sont sécurisées. Il faut des preuves : quelles interfaces existent, dans quelle version, avec quelles autorisations, et qui a consulté quoi, et quand. Le versionnage, les journaux d’accès et un registre des interfaces tenu à jour font de la sécurité non plus une affirmation, mais une propriété démontrable. C’est la logique que NIS2 applique ailleurs à la supervision et à la notification, transposée aux liaisons entre systèmes.
Une chaîne d’approvisionnement ne vaut que ce que valent ses interfaces. Et une interface que personne ne connaît entièrement ne peut être ni sécurisée ni démontrée.