---
title: "Prévenir les BOLA et les défaillances d'autorisation dans les API"
description: "Prévenez les failles d'autorisation au niveau des objets et l'exposition inter-tenant des API grâce aux contrôles d'objet, à l'accès aux données limité au tenant, aux tests adversariaux, à la journalisation et à la réponse aux incidents."
canonical_url: https://optimi.com/fr/guides/preventing-bola-authorization-failures-apis
md_url: https://optimi.com/fr/guides/preventing-bola-authorization-failures-apis.md
last_updated: 2026-07-15
---

# 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.

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.

## 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**

1. Vérifier le principal — Validez l'émetteur, l'audience, l'expiration et le contexte d'identifiant.
2. Déduire le tenant — Utilisez une identité ou un contexte de charge de travail de confiance, jamais un en-tête de tenant client.
3. Charger l'objet limité — Interrogez dans le périmètre du tenant et de la relation.
4. Évaluer l'action — Appliquez les restrictions de propriété, de politique et de contexte.
5. 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**

![Organigramme dans lequel une requête API portant sur un objet vérifie d'abord un principal, déduit un tenant de confiance et le contexte de politique, charge l'objet dans le périmètre du tenant, puis évalue l'action demandée. Les contrôles échoués renvoient un résultat non authentifié ou un refus cohérent ; tous les résultats enregistrent des preuves de décision sûres.](/diagrams/preventing-bola-authorization-failures-apis/object-access-decision.svg)

*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.*

## 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.

## É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

- [Protection des API à la périphérie](/fr/guides/api-protection-edge)
- [Conception d'API fiables](/fr/guides/reliable-api-design)
- [Webhooks sécurisés](/fr/guides/secure-webhooks)

## Références faisant autorité

- [OWASP API1:2023 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/)
- [OWASP : aide-mémoire sur l'autorisation](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
- [OWASP : aide-mémoire sur la sécurité multi-tenant](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html)
- [NIST SP 800-162 : contrôle d'accès fondé sur les attributs](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-162.pdf)
- [RFC 9700 : bonnes pratiques de sécurité OAuth 2.0](https://www.rfc-editor.org/rfc/rfc9700.html)

[Examiner l'autorisation des API](/fr/contact): 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.