Guide de sécurité des API

Prévenir les BOLA et les défaillances d'autorisation dans les API

Un appelant authentifié, un jeton valide et une permission au niveau de la route ne prouvent pas que l'appelant peut agir sur l'objet précis de la requête.

Publié le: 15 juil. 2026
Mis à jour le: 15 juil. 2026
Temps de lecture: 13 min de lecture

Sur cette page

Une autorisation défaillante au niveau des objets, aussi appelée IDOR dans de nombreux contextes applicatifs, survient lorsqu'un appelant peut modifier une référence d'objet et lire, changer ou supprimer un enregistrement sans la relation requise. Un WAF, une limite de débit ou une passerelle API peut réduire les abus et valider des identifiants généraux ; il n'est normalement pas l'autorité de la relation actuelle entre l'appelant A et l'objet B.

Overview

Résultat attendu

Faites des contrôles au niveau des objets et limités au tenant un invariant de livraison pour les routes API, le travail en arrière-plan, le stockage, les caches et les chemins de service alternatifs.

Rendre explicite la question de l'autorisation

Chaque requête portant sur un objet nécessite un principal vérifié, l'action demandée, l'objet précis, le tenant et le contexte pertinent. Refusez par défaut, puis accordez l'accès par une propriété, une adhésion, une relation déléguée, un rôle ou une politique explicite. Les permissions au niveau des fonctions et l'autorisation au niveau des objets sont complémentaires, et non interchangeables.

Décision d'autorisation d'objet

Vérifier le principal
Validez l'émetteur, l'audience, l'expiration et le contexte d'identifiant.
Déduire le tenant
Utilisez une identité ou un contexte de charge de travail de confiance, jamais un en-tête de tenant client.
Charger l'objet limité
Interrogez dans le périmètre du tenant et de la relation.
Évaluer l'action
Appliquez les restrictions de propriété, de politique et de contexte.
Enregistrer la décision
Journalisez des preuves sûres et renvoyez un résultat cohérent.

Le service et le chemin de données doivent évaluer la relation avec l'objet demandé après la vérification de l'identité et avant de renvoyer ou modifier les données.

L'accès à un objet exige une identité, un périmètre et une décision d'action

Un jeton valide n'est qu'un point de départ : le service doit prendre une décision limitée au tenant sur l'objet et l'action demandés avant de renvoyer ou modifier les données.

Telecharger:PNG SVG

Limiter au tenant chaque chemin d'accès

Limitez les requêtes de base de données, endpoints de liste, actions en masse, caches, chemins de stockage d'objets, files, index de recherche, résolveurs GraphQL et consommateurs en arrière-plan. Les UUID, identifiants signés et URL opaques réduisent l'énumération facile, mais ne constituent jamais une autorisation. Un appelant qui obtient un identifiant valide doit toujours être refusé en l'absence de relation.

Couche	Contrôle requis	Contournement courant
Gestionnaire API	Contrôle de l'objet et de l'action	Alias de route ou version alternative de l'API
Accès aux données	Requête limitée au tenant ou défense au niveau des lignes	Méthode de dépôt sans périmètre
Cache	Éligibilité et clé tenant-aware	Décision mise en cache qui survit à un changement d'adhésion
Worker ou export	Même contexte de politique	Job asynchrone qui fait confiance à l'identifiant d'objet soumis
Passerelle	Jeton et politique générale de route	Passerelle supposée connaître la relation avec l'objet

Résultat représentatif de test BOLA

principal=tenant-A:user-1 action=read object=tenant-B:invoice-472
api_status=404 decision=deny policy_version=2026.07
cache_state=bypass audit_event=recorded
cross_tenant_regression=pass

Tester de manière adversariale avant la livraison

Construisez une matrice de contrôle d'accès avec au moins deux identités dans un tenant et deux tenants. Pour chaque API portant sur un objet, testez les opérations de lecture, création, mise à jour, suppression, export, téléchargement, liste, filtre, pagination, lot, GraphQL et asynchrones. Modifiez les identifiants d'objet dans les chemins, paramètres de requête, champs du corps, objets imbriqués et URL signées. Une livraison doit échouer si une opération inter-utilisateur ou inter-tenant réussit.

Utilisez 401 pour une authentification absente ou invalide et 403 pour un appelant authentifié sans permission. Un 404 cohérent peut être un choix intentionnel pour masquer l'existence d'un objet, mais il ne doit pas masquer une décision d'autorisation ni rendre l'enquête d'incident impossible.

Journaliser les décisions et préparer le confinement

Enregistrez l'horodatage, l'identifiant de requête, le principal vérifié ou l'identité de charge de travail, le tenant, l'action, le type de ressource, une référence d'objet sûre, la version de politique, le motif de décision et le service source. Ne journalisez ni jetons ni payloads sensibles complets. En cas d'exposition soupçonnée, désactivez l'action vulnérable, révoquez les sessions ou clés concernées, conservez les preuves, identifiez les tenants et objets affectés, corrigez chaque chemin alternatif, invalidez les caches et URL signées associés, et ajoutez des tests de régression.

Troubleshooting

Échecs de prévention des BOLA

Faire confiance à un tenant_id fourni par l'appelant ou le transférer sans frontière de proxy protégée.
Traiter la portée d'un JWT comme une permission pour chaque objet d'un type.
Appliquer les contrôles dans un gestionnaire HTTP, mais pas aux exports, workers, résolveurs GraphQL ou URL de stockage.
Utiliser les blocages WAF ou les limites de débit pour masquer une requête non autorisée qui a réussi.

Guides connexes

Références faisant autorité

Faites de l'isolation des tenants un invariant d'API

Optimi peut vous aider à relier les contrôles de route, l'autorisation à l'origine, une télémétrie sûre et la protection edge sans prétendre que l'edge possède les permissions sur les objets.

Examiner l'autorisation des API