API3 Broken Object Property Level Authorization

devsecops

Définition

API3 Broken Object Property Level Authorization (anciennement Excessive Data Exposure) est le troisième risque de l'OWASP API Security Top 10 (2023). Il couvre deux sous-problèmes liés à la gestion des propriétés d'objets dans les réponses et requêtes API : l'exposition excessive de propriétés (l'API retourne plus de données qu'elle ne devrait) et le mass assignment (l'API accepte des modifications de propriétés qu'elle ne devrait pas permettre). L'exposition excessive de données se produit quand une API retourne l'objet complet du modèle de données (incluant des champs internes, des données sensibles, ou des champs réservés à l'administration) et délègue le filtrage au client. Par exemple, un endpoint /api/users/{id} retournant le hash du mot de passe, le token de reset de mot de passe, et les rôles internes dans la réponse JSON, en espérant que le client frontend n'affichera que les champs pertinents. Un attaquant peut ignorer cette logique côté client et accéder à toutes les données retournées. Le Mass Assignment se produit quand une API accepte et applique des propriétés non autorisées dans les requêtes de modification. Par exemple, un PUT /api/users/{id} acceptant {name: "Alice", role: "admin"} sans filtrer le champ "role" — permettant à un utilisateur ordinaire de s'octroyer des droits administrateur.

Exposition excessive vs Mass Assignment

L'exposition excessive : l'API sérialise l'objet complet (y compris password_hash, internal_notes, admin_flag) en espérant que le client filtre. Correction : utiliser des serializers avec whitelist de champs exposables (API Resource classes en Laravel, Serializer Groups en Symfony, Data Transfer Objects en Java). Le Mass Assignment : l'API accepte et applique n'importe quelle propriété du corps de la requête. Correction : utiliser des formulaires/DTOs avec liste blanche des champs modifiables, jamais Object.assign(dbModel, requestBody).

Patterns de correction

Pour l'exposition : créer des "views" ou "projections" explicites des objets selon le contexte (vue publique, vue authentifiée, vue admin) via des serializers/DTOs. Pour le mass assignment : valider et filtrer explicitement les champs modifiables (allowlist) dans chaque endpoint de modification — le champ "role" n'est modifiable que dans /admin/users/{id}, jamais dans /api/users/{id}. Les frameworks modernes (Laravel Eloquent $fillable/$guarded, Django serializer fields) facilitent ces contrôles.

Détection et tests

Tests de Mass Assignment : envoyer des propriétés non documentées dans les requêtes de modification (role, is_admin, credits) et vérifier qu'elles sont ignorées. Tests d'exposition excessive : comparer les champs retournés par l'API avec les champs réellement nécessaires côté client — tout champ exposé mais non utilisé est candidat à la suppression. Les outils DAST spécialisés API (Portswigger, 42Crunch) peuvent détecter automatiquement certains patterns d'exposition excessive.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis