Vous connaissez peut-être Cloudflare comme l'entreprise soutenant près de 20 % d'Internet, mais le soutien et la protection des sites web et du contenu statique ne représentent qu'une fraction de nos activités. Pour tout dire, bien plus de la moitié du trafic dynamique circulant sur notre réseau n'est pas lié aux pages web, mais aux interfaces de programmation d'applications (Application Programming Interfaces, API), soit la tuyauterie qui permet de faire fonctionner la technologie. Cet article de blog présente et complète le rapport 2024 consacré à la gestion et à la sécurité des API, dans lequel nous détaillons de quelle manière nous protégeons exactement nos clients et les implications de cette protection pour l'avenir de la sécurité des API. Contrairement aux autres rapports sur les API proposés dans le secteur, le nôtre n'est pas basé sur des enquêtes menées auprès des utilisateurs, mais sur des données du trafic réel.
S'il est un élément que vous devez retenir de notre rapport de cette année, c'est celui-ci : de nombreuses entreprises ne disposent pas d'un inventaire précis de leurs API, même lorsqu'elles pensent qu'elles peuvent correctement identifier le trafic lié à ces dernières. Cloudflare aide les entreprises à identifier l'ensemble de leurs API publiques en suivant deux approches. Dans la première, les clients configurent notre outil d'identification des API afin de se mettre à la recherche des jetons d'identification présents dans le trafic de leurs API connues. Dans la deuxième, nous appliquons un modèle de Machine Learning (apprentissage automatique) qui analyse non seulement les appels à ces API connues, mais également l'ensemble des requêtes HTTP, afin d'identifier le trafic susceptible d'être passé inaperçu. La différence entre ces deux approches est frappante : nous avons découvert 30,7 % de points de terminaison d'API supplémentaires par l'intermédiaire de l'identification basée sur le Machine Learning plutôt que via l'approche autonome. Ce chiffre suggère que près d'un tiers des API sont des « API fantômes », qui ne peuvent être correctement inventoriées et sécurisées.
Poursuivez votre lecture pour découvrir des informations supplémentaires et les points saillants de notre premier rapport sur la sécurité des API. Dans le rapport intégral, vous trouverez des statistiques mises à jour concernant les menaces que nous repérons et bloquons, ainsi que nos prévisions pour l'année 2024. Nous prévoyons ainsi que le manque d'attention des entreprises envers la sécurité des API conduira à une hausse de la complexité et de la perte de contrôle, mais aussi que l'accès accru à l'IA générative entraînera davantage de risques pour les API. Nous anticipons également une augmentation des attaques basées sur la logique métier à l'encontre des API en 2024. Enfin, l'ensemble des risques ci-dessus nécessitera une croissance de la gouvernance autour de la sécurité des API.
Surfaces d'attaque dissimulées
En quoi les pages web et les API diffèrent-elles ? Les API constituent un moyen simple et rapide pour les applications de récupérer des données en fond ou de demander aux autres applications d'accomplir certaines tâches. N'importe qui peut écrire une application météo sans être météorologue, par exemple : un développeur peut rédiger la structure de la page ou de l'application mobile et demander à une API météo de lui transmettre les prévisions en se basant sur l'emplacement géographique de l'utilisateur. Fondamentalement, la plupart des utilisateurs finaux ne savent pas que les données ont été fournies par l'API météo et non par le propriétaire de l'application.
Si les API constituent la tuyauterie essentielle d'Internet, elles sont également une cible privilégiée des abus. Les défaillances dans le processus d'authentification et d'autorisation des API chez Optus ont conduit à ce qu'un acteur malveillant propose 10 millions de dossiers utilisateur à la vente. Les agences gouvernementales ont d'ailleurs émis un avertissement prévenant très exactement le public de ces attaques sur les API. Les développeurs au sein d'une entreprise concevront souvent des API en contact avec le public, utilisées par leurs propres applications pour fonctionner de manière plus efficace, mais c'est à l'équipe de sécurité que revient la tâche de protéger ces nouvelles interfaces publiques. Si le processus de documentation des API et de signalement de ces dernières à l'attention de l'équipe de sécurité n'est pas clair, elles deviennent des API fantômes, fonctionnelles dans l'environnement de production, mais à l'insu de l'entreprise. C'est à ce moment que les difficultés en matière de sécurité commencent à émerger.
Pour aider les clients à résoudre ce problème, nous avons lancé la solution API Discovery (Identification des API). Lors de la présentation de notre dernière sortie, nous avons mentionné à quel point les entreprises qui disposaient d'un inventaire de leurs API étaient rares. Les équipes de sécurité sont parfois contraintes d'adopter une approche « e-mail et demande de liste » (email and ask) pour établir cet inventaire, mais les réponses deviennent immédiatement obsolètes lors de la sortie de la nouvelle version d'une application, car les API changent. Le mieux à faire consiste à surveiller les changements des API grâce aux changements de la base de code, afin de suivre le rythme des nouvelles versions. Cette démarche présente toutefois le désavantage de n'inventorier que le code entretenu de manière active. Les applications d'ancienne génération peuvent ne pas connaître de nouvelles versions, malgré le fait qu'elles traitent du trafic de production.
L'approche de Cloudflare envers la gestion des API implique l'établissement d'un inventaire complet et précis des API en combinant un service d'identification des API basé sur le Machine Learning (apprentissage automatique) à l'inspection du trafic réseau. Ce service est intégré à notre produit API Gateway, au sein duquel les clients peuvent gérer leurs points de terminaison en contact avec Internet et surveiller l'intégrité de leurs API. La solution API Gateway permet également aux clients d'identifier leur trafic d'API à l'aide d'identifiants de session (en général, un en-tête ou un cookie). Cette fonctionnalité les aide ainsi à identifier spécifiquement le trafic lié aux API afin de soutenir le processus de recherche de ces dernières.
Comme nous l'avons remarqué précédemment, notre analyse montre que même les clients avertis omettent des pans entiers de leur trafic d'API. En comparant le processus de recherche basé sur la session (en faisant usage de sessions d'API pour circonscrire le trafic) à notre service d'identification des API basé sur le Machine Learning (qui analyse l'ensemble du trafic entrant), nous avons découvert que ce dernier service permettait de révéler en moyenne 30,7 % de points de terminaison supplémentaires ! Sans une large analyse du trafic, vous pourriez passer à côté de près d'un tiers de votre parc d'API.
Si vous n'êtes pas client de Cloudflare, vous pouvez néanmoins commencer à établir l'inventaire de vos API. Les API sont généralement cataloguées sous un format normalisé nommé OpenAPI et de nombreux outils de développement peuvent compiler des fichiers de schémas sous ce format. Si vous disposez d'un fichier au format OpenAPI, vous pouvez commencer à dresser vous-même un inventaire de vos API en recueillant ces schémas. Vous trouverez ci-dessous un exemple de la manière dont vous pouvez extraire les points de terminaison d'un fichier de schéma. Cet exemple part du principe que vous disposez d'un fichier au format OpenAPI v3 nommé « my_schema.json » :
À moins que vous n'ayez commencé à générer des schémas OpenAPI et suivi votre parc d'API depuis le début du processus de développement de votre application, il vous manque probablement quelques points de terminaison sur l'ensemble de l'inventaire d'API de votre application de production.
import json
import csv
from io import StringIO
# Load the OpenAPI schema from a file
with open("my_schema.json", "r") as file:
schema = json.load(file)
# Prepare CSV output
output = StringIO()
writer = csv.writer(output)
# Write CSV header
writer.writerow(["Server", "Path", "Method"])
# Extract and write data to CSV
servers = schema.get("servers", [])
for server in servers:
url = server['url']
for path, methods in schema['paths'].items():
for method in methods.keys():
writer.writerow([url, path, method])
# Get and print CSV string
csv_output = output.getvalue().strip()
print(csv_output)Un contrôle précis du volume de requêtes minimise le potentiel d'attaques
Lorsqu'il s'agit de mettre un terme aux abus, la première pensée qui vient à l'esprit des utilisateurs confirmés est le contrôle du volume de requêtes. La mise en place d'un contrôle sur votre API est un outil bien utile pour maîtriser les abus et empêcher la surcharge accidentelle de l'origine. Mais comment savoir si vous avez sélectionné la bonne approche en matière de contrôle du volume ? Les approches varient, mais tournent généralement autour du code d'erreur choisi et de la base choisie pour la limite en elle-même.
Pour certaines API, les utilisateurs confirmés configurent les erreurs du contrôle du volume de requêtes afin de renvoyer un code HTTP 403 (Forbidden, Accès interdit), tandis que d'autres renverront un code HTTP 429 (Too Many Requests, Trop de requêtes). L'utilisation du code HTTP 403 semble tout à fait anodine, jusqu'à ce que vous vous aperceviez que d'autres outils de sécurité renvoient eux aussi des codes 403. Lorsque vous êtes sous le feu d'une attaque, il peut s'avérer difficile de savoir quel outil est responsable de quelle erreur/action de blocage.
De l'autre côté, si vous utilisez le code HTTP 429 pour contrôler le volume des requêtes, les acteurs malveillants sauront instantanément qu'ils ont fait l'objet d'un contrôle et pourront « surfer la vague » pour se placer juste sous la limite sans être détectés. Ce choix peut être pertinent si vous n'avez mis en place le contrôle du volume dans l'unique but de vous assurer que votre back-end reste en ligne, mais il peut rebattre les cartes en faveur des pirates. En outre, les acteurs malveillants peuvent « étaler » leur flux sur davantage de clients d'API afin d'envoyer effectivement un volume de requêtes supérieur à la limite.
Les deux approches présentent des avantages et des inconvénients, mais nous remarquons que la majorité des API renvoient des codes HTTP 420 sur l'ensemble des messages d'erreur 4xx et 5xx (presque 52 %).
Qu'en est-il de la logique de la règle de contrôle du volume de requêtes en elle-même et non du seul code de réponse ? La mise en œuvre de limitations du volume de requêtes sur les adresses IP peut s'avérer tentante, mais à titre de bonne pratique, nous vous recommandons de baser la limite sur un identifiant de session et de ne vous rabattre sur l'adresse IP (ou l'empreinte JA3 + IP) que lorsque les identifiants de session ne sont pas disponibles. La configuration d'un contrôle du volume de requêtes sur les sessions utilisateur plutôt que sur les adresses IP permettra d'identifier vos utilisateurs réels de manière fiable et de minimiser les faux positifs dus à un espace IP partagé. Le service Advanced Rate Limiting (contrôle du volume de requêtes) et la protection contre les abus volumétriques de la solution API Gateway facilitent l'application de ces limites en dressant le profil du trafic de session sur chaque point de terminaison d'API et en permettant aux solutions en un clic de configurer la limite en fonction du point de terminaison.
Pour déterminer la valeur de vos limites, la solution API Gateway de Cloudflare calcule pour vous les statistiques des requêtes d'une session. Après examen de la répartition des requêtes par session sur l'ensemble des sessions, nous suggérons une limite à votre API telle qu'identifiée par l'identifiant de session d'API configuré par le client. Nous calculons ensuite les valeurs-p statistiques (qui décrivent les volumes de requêtes pour différentes cohortes de trafic) pour p50, p90 et p99 dans cette répartition et utilisons la variance de la répartition afin d'aboutir à un seuil recommandé pour chaque point de terminaison unique de votre inventaire d'API. La recommandation pourrait ne pas correspondre aux valeurs-p, soit un fait qui fait une différence importante et constitue une raison de ne pas utiliser les valeurs-p seules. En plus de fournir une recommandation, la solution API Gateway informe les utilisateurs de notre degré de confiance envers cette recommandation. En règle générale, plus nous pouvons collecter de sessions d'API, plus notre degré de confiance envers la recommandation sera élevé.
L'activation du contrôle du volume de requêtes consiste très simplement à cliquer sur un lien « Créer une règle ». La solution API Gateway transmettra automatiquement votre identifiant de session à la page de création de règle avancée de contrôle du volume, pour s'assurer que vos règles fassent preuve d'une précision extrême afin de vous protéger contre les attaques et de minimiser les faux positifs par rapport aux limites traditionnelles, bien trop larges.
Les API sont également victimes des attaques sur les applications web
Les API ne sont pas immunisées aux attaques normales du Top 10 de l'OWASP, comme l'injection SQL. Le corps des requêtes d'API peut également trouver son chemin sous forme d'entrée de base de données, tout comme une entrée de formulaire sur une page web ou un paramètre d'URL. Il est important de vous assurer que vous disposez bien d'un pare-feu d'applications web (WAF) protégeant également votre trafic d'API afin de vous défendre contre ces attaques.
Pour tout dire, lorsque nous avons examiné les règles gérées du pare-feu WAF de Cloudflare, les attaques par injection étaient le deuxième vecteur de menaces le plus courant envers les API. Les anomalies HTTP étaient la menace la plus fréquente. Les noms de méthodes mal formés, les caractères nuls, les ports non standard ou une longueur de contenu de zéro dans une requête POST constituent de bons exemples d'anomalies HTTP. Vous trouverez ci-dessous les statistiques concernant les autres menaces principales que nous avons observées à l'encontre des API :
La violation de l'authentification et de l'autorisation ne figure pas dans la liste. Ce type de violation se produit lorsqu'une API ne parvient pas à vérifier si l'entité qui lui envoie des requêtes d'informations a bien l'autorisation de demander ces données ou non. Elle peut également survenir lorsque des attaques tentent de falsifier des identifiants et d'insérer des autorisations moins limitées à leurs identifiants (valides) existants, alors qu'ils présentaient jusqu'ici un degré d'autorisation restreint. L'OWASP catégorise ces attaques de différentes manières, mais les catégories principales sont les attaques par violation de l'autorisation au niveau de l'objet (Broken Object Level Authorization, BOLA) et violation de l'autorisation au niveau de la fonction (Broken Function Level Authorization, BFLA).
La cause première d'une attaque BOLA/BFLA réussie réside dans l'incapacité pour l'origine d'une API de contrôler la propriété appropriée des enregistrements de base de données par rapport à l'identité sollicitant ces enregistrements. Il peut s'avérer difficile de suivre ces attaques spécifiques, car la structure d'autorisation peut tout simplement être absente, inadéquate ou mal implémentée. Voyez-vous à quel problème du type « l'œuf ou la poule » nous arrivons ici ? Ces attaques seraient faciles à bloquer si nous avions connaissance de la structure d'autorisation appropriée, mais si nous connaissions (nous ou nos clients) cette structure ou si nous pouvions garantir sa mise en application, les attaques n'aboutiraient pas pour commencer. Surveillez le lancement de nouvelles fonctionnalités de la solution API Gateway dans lesquelles nous mettrons à profit notre connaissance des normes de trafic d'API pour suggérer des politiques de sécurité qui révèlent et bloquent les attaques BOLA/BFLA.
Vous trouverez ci-dessous quatre moyens de combler les lacunes du processus d'authentification auxquelles vos API peuvent potentiellement faire face, même si vous ne disposez pas d'une politique d'autorisation configurée avec précision :
Pour commencer, appliquez une authentification à chaque API publiquement accessible, sauf exception approuvée par l'activité. Faites appel aux technologies telles que le mTLS ou les Web Tokens JSON.
Limitez la vitesse des requêtes d'API vers vos serveurs afin de ralentir les pirates potentiels.
Bloquez les volumes anormaux de flux de données sensibles sortants.
Empêchez les acteurs malveillants d'ignorer les séquences légitimes de requêtes d'API.
Les API suivent étonnamment le rythme des humains, et non plus celui de la machine
Si vous travaillez dans le secteur de la technologie depuis une période antérieure aux smartphones, lorsque le nombre d'utilisateurs qui avaient l'habitude d'être en ligne était plus réduit, il peut être tentant de voir les API comme des outils uniquement utilisés pour la communication machine-machine, un peu à l'instar d'un processus de traitement par lots effectué la nuit. Or, la vérité ne pourrait pas être plus différente. Comme nous l'avons déjà vu, de nombreuses applications web et mobiles sont soutenues par des API, qui facilitent toutes les tâches, de l'authentification aux transactions, en passant par la diffusion de fichiers multimédias. Plus les utilisateurs emploient ces applications, plus nous constatons une augmentation correspondante du volume de trafic lié aux API.
Nous pouvons illustrer la situation en examinant les schémas de trafic d'API observés pendant les jours fériés, c'est-à-dire au moment où les collaborateurs des entreprises se réunissent en famille ou avec leurs amis, et qu'ils passent davantage de temps à socialiser entre eux et moins en ligne. Nous avons annoté le graphique suivant (représentant le trafic lié aux API à travers le monde) en lui ajoutant les fêtes et les jours fériés courants. Remarquez de quelle manière le trafic connaît des pics de l'ordre de +10 % autour de Black Friday et de Cyber Monday lorsque les utilisateurs effectuent des achats en ligne, mais qu'il s'effondre lors des jours situés autour de Noël et du Nouvel An.
Ce schéma ressemble fortement à ce que nous observons au niveau du trafic HTTP normal. Il apparaît clairement que les API ne relèvent plus simplement du royaume des processus automatisés, mais qu'elles sont étroitement liées aux comportements humains et aux tendances sociales.
Recommandations
Il n'existe pas de méthode miracle pour mettre en place une sécurité globale des API. Pour obtenir le meilleur résultat, Cloudflare recommande quatre stratégies destinées à renforcer le niveau de sécurité de vos API :
Associer le développement d'applications, la visibilité, les performances et la sécurité des API à un plan de contrôle unifié capable de tenir un inventaire d'API à jour.
Utiliser des outils de sécurité reposant sur des technologies d'apprentissage automatique pour libérer des ressources humaines et réduire les coûts.
Adopter un modèle de sécurité positive pour vos API (voir ci-dessous pour une explication des modèles de sécurité positive et négative).
Mesurer et améliorer le niveau de maturité en matière d'API de votre entreprise au fil du temps (voir également ci-dessous pour une explication du niveau de maturité en matière d'API).
Que voulons-nous dire par modèle de sécurité « positive » ou « négative » ? Dans un modèle de sécurité négative, les outils recherchent des signes d'attaque connus et agissent pour mettre un terme à ces attaques. Dans un modèle de sécurité positive, les outils recherchent les requêtes connues pour être fiables et ne laissent passer que ces dernières. Ils bloquent toutes les autres. Les API sont souvent structurées de manière à ce que les modèles de sécurité positive fassent sens pour les plus hauts niveaux de sécurité. Vous pouvez également combiner les modèles de sécurité, par exemple, en utilisant un pare-feu WAF dans le cadre d'un modèle négatif et la validation de schéma d'API dans le cadre d'un modèle positif.
Voici un moyen rapide d'évaluer le niveau de maturité de votre entreprise en termes de sécurité des API au fil du temps : les entreprises novices commenceront par dresser l'inventaire de leurs API, peu importe à quel point il est incomplet. Les entreprises plus matures s'efforceront d'obtenir un inventaire précis de leurs API et de mettre en œuvre des mises à jour automatiques. Les entreprises les plus matures appliqueront activement des mesures de contrôle de sécurité à leurs API dans le cadre d'un modèle de sécurité positive, afin de mettre en place le schéma d'API et une authentification valide, tout en contrôlant les comportements à la recherche de signes d'abus.
Prévisions
Pour terminer, voici nos quatre prévisions principales pour l'année 2024 et au-delà :
Accélération de la perte de contrôle et de la complexité : nous avons interrogé des utilisateurs confirmés dans le domaine de la gestion et de la sécurité des API, et 73 % ont répondu que les exigences en matière de sécurité interféraient avec leur productivité et leur capacité d'innovation. Combinés à la prolifération des applications et des inventaires incomplets, les risques et la complexité des API continueront d'augmenter.
Un accès facilité à l'IA menant à davantage de risques visant les API : l'essor de l'IA générative entraîne des risques potentiels, notamment le risque que les API des modèles d'IA soient vulnérables aux attaques, mais aussi celui que les développeurs sortent du code buggé, rédigé par IA. Forrester prédit qu'en 2024, sans les garde-fous appropriés, « au moins trois violations de données seront publiquement imputées à du code non sécurisé généré par IA, que ce soit du fait de failles de sécurité dans le code généré lui-même ou de vulnérabilités dans les dépendances suggérées par l'IA ».
Augmentation des fraudes basées sur la logique métier : les fraudeurs professionnels dirigent leurs opérations comme de véritables entreprises et connaissent des coûts comme ces dernières. Nous nous attendons à ce que les acteurs malveillants lancent leurs bots fraudeurs contre les API de manière encore plus efficace que les années précédentes.
Inflation de la gouvernance : la première version de la norme PCI DSS à aborder directement la sécurité des API entrera en vigueur au mois de mars 2024. Contrôlez les exigences spécifiques à votre secteur avec votre service d'audit afin de vous préparer à leur arrivée.
Si vous souhaitez le consulter dans son intégralité, vous pouvez télécharger le rapport 2024 consacré à la gestion et à la sécurité des API ici. Vous y retrouverez les détails complets de nos recommandations.
Notre solution de sécurité des API Cloudflare API Gateway est disponible à l'ensemble de nos clients Enterprise. Si vous n'êtes pas abonné à la solution API Gateway, cliquez ici pour afficher les résultats de votre identification des API initiales dans le tableau de bord Cloudflare API Gateway et commencer votre essai. Pour apprendre à utiliser la solution API Gateway afin de sécuriser votre trafic, cliquez ici pour consulter nos documents de développement et ici pour télécharger notre guide de démarrage.