Contrôle d'accès défaillant.

Le contrôle d'accès défaillant a atteint la première place du Top 10 OWASP (2021), apparaissant dans 94 % des applications testées par OWASP et se rattachant à 34 CWE, dont CWE-284, CWE-639 et CWE-862 (autorisation manquante). Il survient lorsqu'une application n'applique pas systématiquement qui peut faire quoi : vérifications absentes côté serveur, confiance dans des URLs cachées (sécurité par obscurité), confiance dans des informations de rôle fournies par le client, ou exposition de références directes à des objets sans vérification de propriété.

Comment ça dérape

L'autorisation doit être réévaluée sur le serveur pour chaque requête. L'erreur classique consiste à ne l'appliquer que dans l'interface ou au niveau de la passerelle, puis à faire confiance à l'identifiant envoyé par le client. Un attaquant rejoue alors simplement la requête avec un identifiant d'objet, un paramètre de rôle ou une méthode HTTP différents.

flowchart TD
  A[Requête : GET /api/invoice/1043] --> B{Authentifié ?}
  B -->|Non| R[401 Rejet]
  B -->|Oui| C{Vérification de propriété / rôle<br/>appliquée côté serveur ?}
  C -->|Absente| L[Renvoie la facture 1043<br/>même si elle appartient à un autre client]
  C -->|Présente| D{Le sujet possède-t-il l'objet<br/>ou dispose-t-il du rôle requis ?}
  D -->|Non| F[403 Interdit]
  D -->|Oui| G[200 Renvoie la ressource]
  L --> X[Contrôle d'accès défaillant :<br/>IDOR / divulgation de données]

Incidents réels

La fuite de First American Financial (2019) a exposé environ 885 millions de documents hypothécaires via un IDOR classique : des URLs séquentielles ne nécessitaient aucune authentification. La fuite d'Optus (2022, Australie) a exposé environ 9,8 millions de dossiers clients via un point d'accès d'API non authentifié. USPS Informed Visibility (2018) permettait à tout utilisateur connecté d'interroger les données de compte d'autrui via une API non protégée.

Défenses

Utilisez un middleware d'autorisation centralisé, en refus par défaut ; appliquez la vérification de propriété pour chaque action côté serveur ; préférez des identifiants opaques ou à portée limitée ; journalisez les échecs de contrôle d'accès et alertez sur les anomalies ; désactivez le listage de répertoires ; invalidez la portée des JWT/sessions côté serveur ; et couvrez les chemins d'autorisation par des tests d'intégration et du DAST continu plutôt que par des contrôles manuels ponctuels.