API5 Broken Function Level Authorization

Patterns de vulnérabilité API5 courants

Les patterns API5 les plus fréquents : 1) Endpoint admin accessible à tout utilisateur authentifié (authentification vérifiée, rôle ignoré). 2) Méthode HTTP admin non protégée (GET est public, PUT/DELETE devrait nécessiter des droits). 3) V1 de l'API sans les contrôles ajoutés dans V2 (Zombie API vulnerability). 4) Endpoint de debug ou monitoring laissé accessible en production. 5) Logique d'autorisation incomplète (certains paramètres permettent d'accéder à des fonctions non autorisées via le paramètre ?admin=true).

Implémentation d'un modèle d'autorisation RBAC pour les APIs

Un modèle d'autorisation robuste pour les APIs : RBAC (Role-Based Access Control) ou ABAC (Attribute-Based) implémenté via un middleware centralisé appliqué à tous les endpoints, avec une liste explicite des permissions requises par endpoint (ex: [ROLE_ADMIN, PERMISSION_USER_DELETE] pour DELETE /api/users/{id}). Les frameworks modernes facilitent cela : Spring Security @PreAuthorize, Django permissions, Express.js middleware de role-checking. Le principe "deny by default" garantit que les nouveaux endpoints sans annotation explicite sont bloqués.

Tests automatisés de l'autorisation par fonction

Les tests d'API5 utilisent deux comptes de test avec des rôles différents (user standard, admin). Pour chaque endpoint, tester que l'utilisateur standard reçoit bien un 403 Forbidden sur les endpoints admin, et que l'admin accède correctement aux fonctions autorisées. Ces tests de matrice d'autorisation peuvent être automatisés avec des frameworks comme Tavern (Python) ou des collections Postman paramétrées, et intégrés dans la suite de régression de sécurité du pipeline CI.