Bonnes pratiques de sécurité des API : se défendre contre l'OWASP Top 10

Les interfaces de programmation applicative (API) constituent la tuyauterie de l'internet moderne. Elles permettent aux applications mobiles de dialoguer avec les serveurs, aux services de dialoguer avec les bases de données et aux entreprises de se connecter à leurs partenaires. Parce qu'elles exposent directement la logique applicative et des données sensibles, elles sont une cible de choix pour les attaquants.

Gartner avait prédit que les abus d'API deviendraient le vecteur d'attaque le plus fréquent, et les compromissions récentes très médiatisées le confirment. Sécuriser des API exige un état d'esprit différent de celui appliqué aux applications web traditionnelles.

L'OWASP API Security Top 10

L'Open Web Application Security Project (OWASP) maintient une liste spécifique des risques API les plus critiques. Les comprendre est la première étape de la défense.

1. Broken Object Level Authorization (BOLA)

La reine des vulnérabilités API. Elle survient lorsqu'un endpoint d'API permet à un utilisateur d'accéder à un objet (une photo, une facture, un message) en modifiant simplement l'identifiant dans l'URL, sans vérifier que l'utilisateur est bien propriétaire de cet objet.

Attaque : l'utilisateur A se trouve sur /api/receipts/1001. Il le change en /api/receipts/1002 et consulte le reçu de l'utilisateur B.
Défense : implémentez systématiquement des contrôles d'autorisation au niveau de l'objet. Est-ce que current_user.id == receipt.user_id ?

2. Broken User Authentication

Une authentification faible permet aux attaquants de détourner des comptes. Cela inclut l'acceptation de mots de passe faibles, l'absence de validation de la signature des jetons JWT ou des parcours de récupération de mot de passe non sécurisés.

Défense : utilisez les flux standards OAuth2/OpenID Connect. N'inventez pas votre propre cryptographie. Validez soigneusement les jetons.

3. Broken Object Property Level Allocation (Mass Assignment)

Les API exposent souvent des endpoints qui acceptent un objet JSON et le lient directement à un modèle de base de données. Si l'API ne filtre pas les entrées, un attaquant peut modifier des champs auxquels il ne devrait pas avoir accès.

Attaque : un utilisateur met à jour son profil en envoyant { "username": "admin", "role": "admin" }. Si le backend met aveuglément à jour le champ role, l'utilisateur devient administrateur.
Défense : utilisez des Data Transfer Objects (DTO) ou des listes d'autorisation explicites pour les paramètres d'entrée. Ne liez jamais directement les entrées aux modèles de données internes.

4. Unrestricted Resource Consumption

Les API sont sensibles au déni de service (DoS). Si un endpoint génère une charge importante (par exemple « générer un rapport PDF »), un attaquant peut l'appeler des milliers de fois pour faire tomber le serveur.

Défense : mettez en place du rate limiting et des quotas. Limitez la taille des charges utiles et le temps d'exécution.

5. Broken Function Level Authorization

Idéalement, les fonctions d'administration devraient être masquées. Mais bien souvent, elles sont simplement « dissimulées ». Un attaquant peut deviner le chemin d'API /api/admin/deleteUser. Si le backend ne vérifie pas le rôle de l'utilisateur, l'attaque réussit.

Défense : refusez par défaut. Exigez explicitement des contrôles de rôle Admin sur les endpoints sensibles.

Bonnes pratiques de sécurité des API

Décaler la sécurité vers la gauche (shift left)

N'attendez pas la production pour tester la sécurité.

Tests de contrat : utilisez des spécifications OpenAPI (Swagger) pour définir ce qui est autorisé.
Analyse automatisée : exécutez des outils DAST spécifiquement conçus pour les API (comme StackHawk ou OWASP ZAP) dans votre pipeline CI/CD.

Utiliser une API Gateway

Une API Gateway agit comme point d'entrée unique pour tout le trafic API. Elle peut appliquer de façon centralisée le rate limiting, l'authentification et la journalisation, réduisant ainsi la charge pesant sur chaque microservice.

Superviser et journaliser

On ne peut pas détecter ce que l'on ne voit pas. Journalisez toutes les requêtes API (en masquant les données sensibles). Cherchez les anomalies :

Une seule IP accédant à des milliers d'identifiants d'objets différents (tentative de BOLA).
Un pic soudain d'erreurs 401 Unauthorized.

Le threat intelligence appliqué aux API

Les API sont souvent attaquées par des bots automatisés. Intégrer du threat intelligence permet de bloquer les acteurs malveillants avant même qu'ils n'atteignent votre logique applicative.

isMalicious fournit des données de réputation en temps réel sur les IP qui se connectent à votre API. Si une requête provient d'une IP associée à un botnet ou à un scraper connu, votre API Gateway peut la rejeter immédiatement, ce qui économise des ressources et protège vos données.

Conclusion

Les API exposent fréquemment des opérations privilégiées. Traitez l'OWASP Top 10 avec des identifiants à durée de vie courte, des contrôles d'autorisation explicites, de la validation de schéma, des limites de débit et des journaux d'audit.