BOPLA : Pourquoi la protection de l'Object ID ne suffit pas (Authorization brisée au niveau des propriétés d'objet) 🔍

Dans le paysage en rapide évolution de la sécurité des API, les développeurs ont enfin commencé à maîtriser l’art de la “vérification d’ID”. La plupart des applications modernes vérifient désormais que l’utilisateur A ne peut pas accéder aux données privées de l’utilisateur B simplement en modifiant un user_id dans une URL — une vulnérabilité connue sous le nom de BOLA (Broken Object Level Authorization).

Cependant, une menace plus insidieuse a émergé, qui contourne les vérifications standard au niveau de l’ID et cible directement les attributs qui définissent un objet. Bienvenue dans le monde de BOPLA (Broken Object Property Level Authorization).

Classé comme API3:2023 dans le Top 10 de la sécurité des API OWASP, BOPLA représente la prochaine frontière des vulnérabilités API. Il ne suffit plus de se demander : “Cet utilisateur peut-il voir cet objet ?”. Les équipes de sécurité doivent désormais se demander : “Cet utilisateur peut-il voir ou modifier ces champs spécifiques de l’objet ?”

Cet article propose une plongée approfondie dans BOPLA, explorant ses origines, ses mécanismes — notamment Mass Assignment et Excessive Data Exposure — et comment sécuriser vos API contre les attaques sophistiquées de 2025 et 2026.

1. L’évolution : de BOLA à BOPLA

Pour comprendre BOPLA, il faut d’abord connaître son prédécesseur. BOLA (anciennement IDOR) survient lorsqu’une application donne accès à un objet basé sur un ID fourni par l’utilisateur sans vérifier si celui-ci a le droit d’accéder à cet enregistrement précis.

BOPLA (Broken Object Property Level Authorization) est le frère granulaire de BOLA. Il se produit lorsqu’une API permet à un utilisateur d’accéder ou de modifier des propriétés spécifiques d’un objet qui devraient être restreintes, même si l’utilisateur a un accès légitime à l’objet lui-même.

La fusion OWASP

Dans la mise à jour 2023 du Top 10 de la sécurité des API, OWASP a fusionné deux catégories précédentes — Excessive Data Exposure (API3:2019) et Mass Assignment (API6:2019) — en une seule catégorie unifiée : BOPLA.

La logique était simple : ces deux vulnérabilités proviennent de la même cause racine — un échec à valider l’autorisation au niveau des propriétés plutôt qu’au niveau de l’objet.

2. Pourquoi la sécurité “au niveau de l’objet” échoue

Imaginez une API bancaire numérique. Une utilisatrice, Alice, se connecte et demande les détails de son compte : GET /api/v1/accounts/12345.

Vérification au niveau de l’objet (BOLA) : Le serveur vérifie si le compte 12345 appartient à Alice. C’est le cas. Accès accordé.

Vérification au niveau des propriétés (BOPLA) : Le serveur renvoie l’objet JSON. Cependant, au lieu de simplement renvoyer son solde et le nom du compte, il renvoie toute la ligne de la base de données, y compris internal_credit_score, is_premium_member, et anti_fraud_flags.

Alice connaît maintenant son score de crédit interne et son statut antifraude — des données qu’elle n’était pas censée voir. C’est une Excessive Data Exposure.

Considérons maintenant le cas inverse. Alice veut mettre à jour son nom d’affichage. Elle envoie une requête PATCH :

{
  "display_name": "Alice La Grande",
  "internal_credit_score": 850
}

Si le backend met à jour aveuglément tous les champs fournis dans le corps JSON, Alice a réussi à hacker son propre score de crédit. C’est une Mass Assignment.

Dans les deux cas, la vérification de l’ID de l’objet a réussi, mais l’autorisation au niveau des propriétés a échoué.

3. Le premier pilier : Excessive Data Exposure (fuite de lecture)

L’Excessive Data Exposure se produit lorsqu’une API repose sur le client (le frontend) pour filtrer les données. Les développeurs trouvent souvent plus simple d’envoyer l “objet complet” depuis la base de données vers le frontend, en supposant que si l’UI affiche uniquement le nom d’utilisateur, les autres champs (comme password_hash ou ssn) sont sécurisés.

Les dangers “cachés”

Les hackers n’utilisent pas votre UI. Ils utilisent des outils comme Burp Suite, Postman ou Insomnia pour inspecter la réponse JSON brute.

Scénarios courants en 2025 :

• Le piège de l’objet utilisateur : Une API pour une application de réseaux sociaux renvoie l’objet utilisateur complet lorsqu’on clique sur un profil. Alors que l’UI ne montre qu’une bio, le JSON contient last_login_ip, email_verified_status, et un backup_email.

• La fuite IoT : Les API de maison intelligente renvoient souvent des métadonnées techniques, y compris les SSID Wi-Fi et les jetons internes des appareils, qui peuvent être exploités pour une movement latéral dans un réseau.

• La mine d’or PII : Une étude de recherche 2025 sur les entreprises du S&P 500 a révélé que de nombreux outils “AutoSwagger” (documentation API automatisée) exposaient accidentellement des champs internes dans leurs schémas, menant à d’importantes fuites de PII (Informations Personnelles Identifiables).

Impact réel

Lorsqu’une API renvoie des mots de passe hachés, même salés, cela donne à un attaquant une cible pour une attaque par dictionnaire. Si elle renvoie des rôles internes, cela donne une feuille de route pour une escalade de privilèges.

4. Le second pilier : Mass Assignment (l’attaque d’écriture)

Mass Assignment est le côté “écriture” de BOPLA. Il se produit lorsqu’une application lie automatiquement les données fournies par le client aux modèles de données internes sans une liste d’autorisation stricte.

Les frameworks web modernes (comme Ruby on Rails, Spring Boot, et Express.js) facilitent le développement en permettant le “Object-Relational Mapping” (ORM). Une seule ligne de code peut prendre un corps JSON et le sauvegarder directement dans la base.

Mécanisme d’exploitation

Un attaquant teste l’API en ajoutant des propriétés “devinées” à une requête.

Entrée : PATCH /api/users/me

Corps légitime : {"bio": "Bonjour tout le monde"}

Corps de l’attaquant : {"bio": "Bonjour tout le monde", "role": "admin", "is_verified": true}

Si le développeur utilise une fonction de mise à jour générique comme User.update(req.body), l’attaquant s’est promu lui-même au rang d’administrateur.

Mass Assignment dans la pratique : la propriété “is_admin”

Dans un cas historique célèbre, un chercheur a découvert qu’il pouvait devenir admin sur GitHub en ajoutant un paramètre admin: 1 lors du téléchargement d’une clé publique. Bien que GitHub ait corrigé cela il y a des années, la logique persiste dans des milliers de microservices modernes aujourd’hui.

5. Analyse technique : code vulnérable vs. code sécurisé

Voyons comment cela se manifeste dans un environnement Node.js/Express utilisant un ORM comme Mongoose ou Sequelize.

❌ La méthode vulnérable (Mass Assignment)

app.patch('/api/profile/update', async (req, res) => {
    const user = await User.findById(req.user.id);
    // VULNÉRABLE : attribution aveugle de toutes les propriétés de req.body à l'utilisateur
    Object.assign(user, req.body); 
    await user.save();
    res.json(user); // AUSSI VULNÉRABLE : Excessive Data Exposure (renvoie l'objet complet)
});

Dans cet extrait, un attaquant peut envoyer {"is_premium": true} ou {"account_balance": 99999} et la base de données sera mise à jour en conséquence.

✅ La méthode sécurisée (autorisation au niveau des propriétés)

const _ = require('lodash');

app.patch('/api/profile/update', async (req, res) => {
    const user = await User.findById(req.user.id);

    // SÉCURISÉ : ne permettre la mise à jour que de certains champs non sensibles (Allow-listing)
    const allowedUpdates = _.pick(req.body, ['bio', 'display_name', 'profile_picture']);
    Object.assign(user, allowedUpdates);
    await user.save();

    // SÉCURISÉ : ne renvoyer que les champs nécessaires pour éviter l'exposition de données
    const publicProfile = _.pick(user, ['id', 'username', 'bio', 'display_name']);
    res.json(publicProfile);
});

6. BOPLA en 2025 : l’essor de l’IA et de la découverte automatique

La menace de BOPLA s’est intensifiée en raison de deux tendances majeures :

1. Outils automatisés de découverte d’API

Des outils comme AutoSwagger et Param Miner sont désormais plus sophistiqués. Les attaquants les utilisent pour scanner des paramètres “cachés”. En analysant les conventions de nommage d’une API (par exemple, si un first_name existe, il y a probablement un last_name), des requêtes fuzzées pilotées par IA peuvent découvrir des champs sensibles comme internal_notes ou partner_id que les développeurs ont oublié de masquer.

2. Introspection GraphQL

GraphQL est particulièrement vulnérable à BOPLA. Parce que GraphQL permet aux utilisateurs de “demander exactement ce qu’ils veulent”, un manque d’autorisation au niveau des champs peut permettre à un utilisateur de requêter des champs sensibles qu’il ne devrait pas accéder. Si votre schéma GraphQL n’a pas de directives @auth strictes sur chaque champ, vous êtes par conception “BOPLA-vulnerable”.

7. Impact business de BOPLA

BOPLA n’est pas qu’un simple “bug” technique ; c’est un risque commercial important.

• Fuites de données : Même si vous ne perdez pas toute la base, la fuite de milliers d’adresses email ou de SSN via Excessive Data Exposure entraîne des obligations de déclaration sous GDPR et CCPA.

• Fraude financière : Dans la fintech, Mass Assignment peut conduire à des augmentations de crédit non autorisées, des exonérations de frais ou l’acquisition de statuts “VIP” sans paiement.

• Dommages à la réputation : Rien n’érode la confiance des utilisateurs plus vite qu’une “faille logique” permettant à n’importe quel utilisateur de voir des paramètres privés ou de changer ses propres permissions.

8. Comment prévenir BOPLA : La checklist ultime du développeur

Sécuriser votre API contre les problèmes d’autorisation au niveau des propriétés nécessite une mentalité “Shift Left” — la sécurité doit faire partie de la phase de conception, pas être une réflexion après coup.

1. Implémenter des DTO stricts (Data Transfer Objects)

Ne mappez jamais directement vos modèles de base de données à votre API. Créez une classe ou une interface séparée (un DTO) pour chaque requête et réponse.

• DTO d’entrée : Définit exactement quels champs l’API acceptera.
• DTO de sortie : Définit exactement quels champs l’API renverra.

2. Utiliser des allow-lists (plutôt que des block-lists)

Lors de la mise à jour d’un objet, définissez explicitement quels champs sont “sûrs”.

• Mauvais : “Ignorez les champs role et id.”
• Bon : “N’acceptez que les champs phone_number et address.”

3. Éviter l’automatisation “ToJSON”

Faites attention avec des méthodes comme .toJSON() ou JSON.stringify(object). Dans de nombreux frameworks, ces méthodes sérialisent l’objet entier. Utilisez plutôt des sérialiseurs spécialisés (comme ActiveModel::Serializers en Ruby ou Jackson Views en Java) pour filtrer les propriétés sensibles.

4. Logique d’autorisation au niveau des champs

Pour les champs sensibles (comme is_admin ou subscription_tier), implémentez une vérification secondaire.

Pseudo-code : if (req.body.role && !currentUser.is_superuser) { return 403; }

5. Désactiver l’introspection en production

Pour GraphQL et Swagger/OpenAPI, désactivez l’introspection et l’accès au schéma public en environnement de production pour empêcher les attaquants de “cartographier” vos propriétés d’objet.

6. Tests automatisés (DAST)

Utilisez des outils de Test de Sécurité Applicative Dynamique (DAST) qui recherchent spécifiquement la mass assignment. Les outils modernes tenteront d’ajouter des champs administratifs courants (comme admin, role, is_staff) dans une requête valide pour voir si le serveur les accepte.

9. Tester BOPLA : un mini-guide pour pentesters

Si vous êtes chercheur en sécurité ou ingénieur QA, voici comment chasser BOPLA :

• Analyser les réponses : Capturez une requête GET. Recherchez des champs qui ne sont pas affichés dans l’UI. Y a-t-il des IDs internes ? Des valeurs hachées ? Des booléens comme is_internal ?

• L’astuce “Devinez et vérifiez” pour la mise à jour : Trouvez un endpoint PUT ou PATCH. Essayez d’ajouter un champ trouvé dans une réponse GET que vous ne devriez pas pouvoir modifier.

Exemple : Si le GET renvoie "is_verified": false, essayez d’envoyer un PATCH avec "is_verified": true.

• Polarité des paramètres : Si vous voyez un champ comme notifications_enabled: true, essayez d’envoyer son opposé ou une supposition liée comme admin_access: true.

• Vérifier les anciennes versions : Parfois, la v2 d’une API est sécurisée, mais la v1 (encore active) reste vulnérable à Mass Assignment.

10. Conclusion : La sécurité dans les détails

Au fil de 2026, la complexité des API ne fera que croître. La transition de BOLA à BOPLA marque un mouvement vers une sécurité plus granulaire, basée sur la logique.

Protéger l’Object ID n’est que la “frais d’entrée” pour la sécurité API — c’est le minimum. La vraie protection consiste à comprendre le cycle de vie des données de chaque propriété dans votre application. En implémentant des DTO, des allow-lists strictes et une autorisation robuste au niveau des propriétés, vous vous assurez que votre API ne se contente pas d’ouvrir la bonne porte, mais n’autorise que les invités à voir les bonnes pièces.

Leçon clé : En sécurité API, Less is More. Chaque propriété supplémentaire que vous renvoyez dans une réponse JSON est une fuite potentielle, et chaque propriété non validée que vous acceptez est une porte dérobée potentielle. Gardez vos payloads légers, vos listes blanches serrées, et votre autorisation granulaire.