Qu'est-ce que la sécurité des API ?

Une grande partie de l'Internet moderne repose sur les API pour fonctionner. La sécurité des API est le processus de protection des API contre les attaques et les violations de données.

Objectifs d’apprentissage

Cet article s'articule autour des points suivants :

  • Comprendre les menaces de sécurité communes aux API
  • Expliquer l'authentification et l'autorisation des API
  • Décrire les techniques permettant de sécuriser les API

Copier le lien de l'article

Qu'est-ce que la sécurité des API ?

Une interface de programmation d'application (API) est un moyen pour un logiciel d'interagir avec un autre logiciel. Si un programme ou une application possède une API, des clients externes peuvent lui demander des services.

La sécurité des API est le processus de protection des API contre les attaques. Tout comme les applications, les réseaux et les serveurs peuvent faire l'objet d'attaques, les API peuvent être victimes d'un certain nombre de menaces différentes.

La sécurité des API est un élément essentiel de la sécurité des applications web . La plupart des applications web modernes reposent sur des API pour fonctionner, et les API introduisent un risque supplémentaire pour une application en permettant à des parties extérieures d'y accéder. On peut comparer cette situation à celle d'une entreprise qui ouvre ses bureaux au public : la présence d'un plus grand nombre de personnes dans les locaux, dont certaines peuvent être inconnues des employés de l'entreprise, augmente le risque. De même, une API permet à des personnes extérieures d'utiliser un programme, ce qui introduit un risque supplémentaire pour l'infrastructure du service API.

Quels sont les risques courants en matière de sécurité des API ?

Les stratégies de sécurité des API peuvent contribuer à atténuer ces risques et d'autres encore.

Des mesures d'authentification et d'autorisation fortes permettent de s'assurer que les données ne fuient pas et que seuls les clients autorisés effectuent des demandes d'API. La protection contre les attaques DDoS et la limitation du débit peuvent mettre fin aux attaques DDoS. La validation des schémas et l'utilisation d'un pare-feu d'application web (WAF) peuvent bloquer les exploits de vulnérabilité.

Comment la limitation du débit et l'atténuation des DDoS aident-elles à protéger les API ?

Limitation du débit limite le nombre de fois qu'une personne peut répéter une action dans un certain laps de temps. Si un client d'API dépasse le nombre de requêtes autorisées, la limitation de débit rejettera ou bloquera toute autre requête de sa part pendant un certain temps.

L'atténuation des DDoS permet de stopper les attaques DoS et DDoS. Lors d'une attaque DDoS, un attaquant tente de submerger une API avec un grand nombre de requêtes en un court laps de temps. Ces demandes proviennent souvent de plusieurs sources différentes.

La limitation du débit et l'atténuation des attaques DDoS sont cruciales pour les API, et ce pour plusieurs raisons :

  1. Arrêt des attaques DoS et DDoS. En bloquant ou en abandonnant les requêtes supplémentaires, la limitation du débit et l'atténuation des attaques DDoS empêchent l'API d'être submergée. La limitation de débit seule peut ne pas arrêter les attaques DDoS de faible et lent , mais l'atténuation DDoS peut absorber le trafic supplémentaire quoi qu'il en soit.
  2. En dehors des attaques intentionnelles, certains clients peuvent simplement utiliser une API de manière excessive. Cela coûte au service API en termes de puissance de calcul et peut ralentir le service pour les autres clients. La limitation du débit permet d'éviter que le serveur d'API ne soit surchargé.

Comment les exploits de vulnérabilité sont-ils bloqués ?

Pour qu'un exploit de vulnérabilité fonctionne, les demandes d'API malveillantes doivent être structurées de telle sorte qu'elles amènent l'API à répondre d'une manière non prévue par ses architectes. Il existe plusieurs moyens pour les développeurs d'API de bloquer ces demandes malveillantes. Deux des plus importantes sont à connaître :

  1. Validation de schéma
  2. Règles WAF

Validation de schéma

Le schéma d'une API décrit le comportement attendu d'une API : le type de demandes qu'elle doit recevoir et le type de réponses qu'elle doit fournir. Les demandes invalides qui ne sont pas conformes à ce schéma peuvent amener une API à se comporter de manière inattendue, ce qui peut entraîner une fuite de données. La validation du schéma identifie les demandes et les réponses non valides. En bloquant les réponses invalides, les développeurs d'API peuvent éviter certains types d'attaques et contribuer à prévenir les fuites de données.

Règles du pare-feu d'application Web (WAF)

Un WAF fonctionne comme un pare-feu traditionnel en ce sens qu'il bloque certaines demandes et réponses du réseau et en laisse passer d'autres. Il le fait sur la base d'un ensemble de règles : si une requête ou une réponse enfreint une règle, ou est conforme à une règle, elle est bloquée. Un WAF est déployé devant une API ou une application web et surveille le trafic HTTP .

Il est possible de configurer des règles WAF qui bloquent les modèles de demande et de réponse qui ciblent une vulnérabilité. Les règles WAF peuvent également bloquer les requêtes provenant de certaines adresses IP , ce qui contribue à stopper les attaques de bot et d'autres attaquants.

Pourquoi l'authentification et l'autorisation sont-elles si importantes pour la sécurité des API ?

L'authentification garantit que les demandes d'API proviennent d'une source légitime. L'autorisation permet au serveur d'API de savoir si le client demandeur est autorisé à obtenir les données demandées.

Supposons qu'Alice construise une API et que Bob construise une application Web qui utilise l'API d'Alice. Lorsque l'application de Bob envoie une demande d'API à l'API d'Alice, il joint à la demande un label indiquant "this is from Bob". Cette étiquette authentifie la demande de Bob afin que le serveur API d'Alice sache qu'il doit traiter la demande comme légitime.

Le serveur API d'Alice vérifie également les privilèges dont dispose Bob. Si la demande de Bob concerne des données que l'API d'Alice a étiquetées ", Bob peut les voir,", le serveur répond à la demande. Cependant, l'API d'Alice peut avoir une section de données étiquetée "qui n'est pas destinée à Bob," et le serveur ne doit pas répondre à une demande pour ces données lorsque Bob est le demandeur. C'est pourquoi l'autorisation de est importante.

(En réalité, Bob joindrait une clé ou une autre forme d'authentification aux demandes d'API, et non pas une simple étiquette indiquant "que ceci provient de Bob.")

Il existe plusieurs méthodes d'authentification pour les API. Les plus courantes sont :

1. Clé API

Le client se voit attribuer une clé - une chaîne de caractères unique que seuls lui et le service API connaissent. La clé est jointe à chaque demande d'API. Le serveur API vérifie la clé lorsqu'il reçoit une demande API pour s'assurer qu'elle provient d'un client authentifié.

L'inconvénient de cette méthode d'authentification est que si la clé est volée, un attaquant peut l'utiliser pour se faire passer pour un client légitime et peut alors mener diverses attaques. Il est important de chiffrer les demandes et les réponses à destination et en provenance d'une API à l'aide d'un protocole de chiffrement tel que Transport Layer Security (TLS) - de cette façon, la clé n'est pas exposée en clair lorsqu'elle traverse l'Internet.

2. Nom d'utilisateur et mot de passe

Les demandes d'API peuvent utiliser des informations d'identification classiques (nom d'utilisateur et mot de passe) pour l'authentification via une méthode appelée authentification HTTP. Dans l'authentification HTTP, un nom d'utilisateur et un mot de passe sont codés et ajoutés à l'en-tête HTTP pour toutes les demandes d'API. Le serveur peut comparer ces informations d'identification aux informations d'identification des clients autorisés pour authentifier les demandes.

Cette approche s'accompagne de tous les défis normalement associés aux mots de passe : les mots de passe peuvent être perdus, divulgués, volés, devinés ou partagés avec des parties non fiables. Les mots de passe sont également sujets à des attaques par force brute ( credential stuffing et ), entre autres.

3. Code d'accès

Au lieu d'exiger une authentification directe du client, un serveur d'API peut obtenir un jeton d'authentification d'un serveur d'authentification de confiance à l'aide du protocole OAuth . Pour utiliser l'API, l'utilisateur se connecte à un service tiers au lieu de se connecter directement à l'API. Comme l'approche par nom d'utilisateur et mot de passe, cette méthode d'authentification est vulnérable au "credential stuffing" et à d'autres attaques.

TLS à authentification réciproque (mTLS)

TLS est le protocole de cryptage qui crée une connexion cryptée et authentifiée entre le client et le serveur lors du chargement de pages web. TLS peut également vérifier et authentifier les deux extrémités d'une connexion API.

Dans le cas de TLS mutuel (mTLS), le client et le serveur disposent tous deux d'un certificat TLS . Ils s'authentifient mutuellement à l'aide de ces certificats, garantissant ainsi que les deux sont bien ceux qu'ils prétendent être, sans avoir besoin de recourir à des mots de passe ou à d'autres méthodes d'authentification.

Toutefois, mTLS peut être difficile à mettre en œuvre : tous les points de terminaison de l'API et les clients ont besoin de certificats TLS légitimes, ce qui peut être difficile à faire respecter et à maintenir.

Qu'est-ce que le bouclier API ?

Cloudflare API Shield permet d'activer plusieurs fonctions de sécurité API à partir d'un seul tableau de bord afin de se protéger contre les risques de sécurité API courants. API Shield comprend :

  • mTLS pour l'authentification des points de terminaison de l'API
  • La validation du schéma, qui utilise un modèle de sécurité positive pour n'autoriser que les demandes conformes au schéma de l'API.
  • Prévention des pertes de données (DLP), qui analyse le trafic sortant d'une API pour vérifier la présence de données sensibles.
  • Limitation du débit et atténuation des DDoS pour éviter la surcharge des API

En savoir plus sur API Shield

Service commercial