Don’t worry, be « API » !

Si la mémoire collective fait naître les API[1] dans les années 2000 (Salesforce et les premières API web), la première initiative fut en réalité à la main de Microsoft qui, dès 1985, avait utilisé le « pouvoir fédérateur » (déjà !) des API pour développer un avantage compétitif[2].

Intrinsèquement facilitatrices, les API sont désormais la « norme de fait » en matière de création et connexion entre applications. Mais cette popularité a un coût… Les API – en tant que passerelles vers des données organisées – sont devenues les « pièces de choix » de fraudeurs, puisqu’elles détiennent des informations documentaires sur leurs structures et méthodes de mise en œuvre. Ces informations couplées aux vulnérabilités de sécurité propres aux API (vulnérabilité du code[3], mauvaise authentification, absence de cryptage…) sont alors exploitables pour lancer des cyberattaques et exposer des données sensibles.

L’augmentation croissante des attaques milite donc pour une prise de conscience des dirigeants quant à l’importance de la sécurité de ces actifs critiques (API), notamment pour réduire les risques commerciaux.

Ainsi, sur le deuxième semestre 2022, les attaques ciblant les API ont augmenté de près de 400 %, dont 80 % par le biais d’API authentifiées (source Salt Security).

Parmi les plus courantes, citons entre autres :

• les attaques MITM (interception et modification de communication entre deux systèmes) ;
• les attaques par injection (insertions de données malveillantes pour exploiter une vulnérabilité du système) ;
• les attaques DDoS (génération d’un volume excessif de trafic vers une API en vue d’une interruption de service).

Si la transformation digitale poursuit son avancée en offrant toujours plus de nouvelles opportunités, et ce sous l’impulsion des API, paradoxalement, c’est bien par elles (et le coût de leurs violations) que la réputation de l’organisation victime, comme de nouveaux services, est impactée.

Parmi les dix principaux risques pour la sécurité des API, recensés par l’OWASP[4], on dénombre la violation d’authentification, l’autorisation brisée au niveau de l’objet/sa propriété/sa fonction, falsification de requête côté serveur ou encore le manque de protection contre les menaces automatisées…

Dans nos newsletters antérieures, nous avions évoqué le rôle fondamental des API en tant que « pierre angulaire » du temps réel. Ce dernier qui constitue et caractérise de plus notre quotidien (transactions B2B, gestion des flux de trésorerie/suivi des liquidités, prévision de trésorerie, rapprochement bancaire) est assuré depuis quelques années par une troisième génération d’API (dédiée et asynchrone pour répondre à des besoins de workflow) plutôt que par des approches plus « traditionnelles » (générations antérieures d’API).

Alors, comment renforcer la sécurisation des API ?

Plusieurs stratégies peuvent être déployées. Tout d’abord, citons la conduite d’audits de sécurité et l’évaluation des vulnérabilités. Ensuite, des protocoles d’authentification et d’autorisation forts doivent également être mis en œuvre. Enfin, nous pouvons noter :

• le recours aux notifications « push » où le système de réception transmettra les alertes de notification à l’utilisateur (via son smartphone) ;
• le cryptage pour protéger le transit de données (par exemple entre un serveur et un navigateur), mais en systématisant a minima le recours au protocole SSL (Secure Sockets Layer) ;
• l’authentification à deux facteurs (2FA) via la saisie d’un code supplémentaire en plus du password lui-même.

Face à la banalisation des outils et des services de fraude (API non protégées face à des bots malveillants avancés, exploitation des vulnérabilités des systèmes de prévention de la fraude existants…), les organisations et institutions financières seront confrontées à des défis permanents tandis que la fraude continue de gagner en popularité, confortée par des gains toujours plus croissants pour les fraudeurs.

[1] Interface de Programmation d’Applications

[2] Pour développer les applications pour MS Windows

[3] Une API exposée vers l’extérieur, devra avoir un niveau de maturité du code de niveau M4 vs une API privée avec une maturité de code plutôt M3.

[4] Open Web Application Security Project