Sécurité des API : La programmabilité est requise

Qu'il s'agisse d'applications ou d'API, d'applications traditionnelles, modernes ou d'IA, la programmabilité est un outil clé dans la boîte à outils de sécurité pour traiter les problèmes de sécurité.

L’une des façons dont nous garantissons la sécurité des applications et des API consiste à tester les vulnérabilités et l’exactitude avant de les diffuser auprès des clients et des partenaires. Une technique populaire pour tester les applications et les API est le test fuzz .

Les tests fuzz consistent à envoyer des entrées inattendues (des chaînes au lieu de nombres, des caractères spéciaux, trop longs, trop courts, etc.) pour déterminer la réponse de l'API ou de l'application. Une implémentation robuste gérera ces entrées en les rejetant comme non valides. Mais tout aussi important que de tester la gestion des entrées est de tester le code qui effectue la gestion des entrées.

En d’autres termes, il ne suffit pas que la logique de l’application ou de l’API rejette les entrées non valides ; la logique qui vérifie les entrées non valides doit également être robuste.

Or, comme c’est souvent le cas dans le monde de la sécurité des applications, quelqu’un va concevoir une entrée qui n’était pas attendue ou prise en compte. Nous ignorerons qu’un bon nombre d’implémentations de nettoyage des entrées sont tout simplement mauvaises et prétendrons qu’elles sont toutes robustes et capables de détecter 99 % des malformations.

Même avec cette hypothèse utopique, il y a toujours ce 1% que personne n’a pris en compte. C’est l’une des façons dont naissent les vulnérabilités zero-day.

Parfois, ils sont le résultat d’un défaut dans la pile technologique. C'est peut-être le serveur Web, le serveur d'applications, le serveur GraphQL. Il se peut que cela soit dû à un connecteur vers une source de données, comme une base de données vectorielle utilisée pour prendre en charge le cas d'utilisation de plus en plus populaire de génération augmentée par récupération (RAG) pour l'IA générative. Ou peut-être est-ce dû à l'arrivée de vulnérabilités d'inférence de l'IA, comme Probllama . L’ajout d’un nouveau niveau au sein de l’architecture d’application plus large signifie, après tout, de nouvelles vulnérabilités.

Ce sont les vulnérabilités qui provoquent la panique sur Internet. Ils nous ont donné Apache Killer (2011), HeartBleed (2014), Spectre et Meltdown (2018) et Log4Shell (2021).

Il s’agissait de vulnérabilités imprévues. On ne pouvait pas s’attendre à ce que les développeurs, SecOps, DevSecOps et QA les anticipent. Ils ne pouvaient vraiment pas.

Indépendamment du manque de prévoyance des développeurs et des professionnels de la sécurité, lorsqu’une vulnérabilité zero-day apparaît, il faut faire quelque chose . Surtout si une organisation est vulnérable parce qu’elle utilise la technologie en question. C’est ce qui transforme le risque en menace , et les menaces doivent être neutralisées.

C’est là qu’intervient la programmabilité des services d’application.

La programmabilité des services applicatifs n’a rien de nouveau. Les organisations utilisent la programmabilité depuis les débuts d’Internet pour mettre en œuvre une variété de solutions.

Les utilisations les plus courantes de la programmabilité dans le chemin de données incluent :

1. Sécurité : La programmabilité est essentielle pour atténuer les menaces zero-day et répondre aux risques de sécurité émergents.
2. Médiation des demandes : Facilite les expériences utilisateur transparentes lors des mises à niveau et des migrations d'applications, prend en charge la modernisation et intègre de nouvelles API de manière rentable.
3. Orchestration des services : Intègre les flux de travail et les services tiers dans les applications sans interruption de l'utilisateur, accélérant ainsi les délais de mise sur le marché.
4. Disponibilité : Prend en charge l'équilibrage de charge et les pratiques de livraison modernes telles que les déploiements Canary et les tests A/B.

Nous savons que ces situations sont courantes, car nos données internes nous indiquent qu’elles le sont. Plus de 70 % de nos clients utilisent quotidiennement la programmabilité pour une grande variété de solutions. Certains d’entre eux sont axés sur la sécurité.

Il n’est donc pas surprenant que nous ayons étudié le marché en général et constaté que la programmabilité figurait en tête des capacités techniques importantes pour la sécurité des API.

La polyvalence d’une solution de sécurité API prenant en charge la programmabilité est pratiquement illimitée. Et même si F5 a certainement été le pionnier de cette capacité, elle est devenue un incontournable du marché pour les services d'application en général. Il existe très peu de services d’application, et en particulier ceux axés sur la sécurisation des applications et des API, qui n’offrent pas la programmabilité dans le cadre de leurs fonctionnalités de base.

C’est parce que la programmabilité est la base pour atténuer les menaces zero-day et permettre aux organisations de concevoir plus délibérément des plans de correctifs qui ont un impact sur un pourcentage significatif de leurs systèmes.

La programmabilité fait, eh bien, à peu près tout. Mais dans le domaine de la sécurité, en particulier de la sécurité des API, ce n’est pas seulement un « plus ». C'est un incontournable.

Pour plus d'informations sur les API, consultez notre rapport sur l'état de la stratégie des applications : Sécurité des API.