Un point de terminaison d'API lie l'intégralité du corps JSON au modèle utilisateur, de sorte qu'un utilisateur peut envoyer `"isAdmin": true`. De quoi s'agit-il, et quelle est la correction ?

Le point de terminaison prend l'objet JSON entrant tout entier et mappe chaque propriété directement sur le modèle utilisateur. Un client normal envoie name et email ; un attaquant ajoute "isAdmin": true et le framework le définit consciencieusement. C'est l'affectation en masse (aussi appelée over-posting ou auto-binding), une forme d'autorisation défaillante au niveau des propriétés d'objet.

La bonne correction : liaison sur liste blanche côté serveur

Décidez, côté serveur, exactement quels champs une requête donnée est autorisée à définir, et ne liez que ceux-là. Concrètement :

• Utilisez un DTO / modèle de vue / « strong parameters » qui ne contient que les champs modifiables pour cette opération, et mappez à partir de lui — ne liez jamais la requête brute directement au modèle de persistance.
• Traitez les attributs privilégiés (isAdmin, role, balance, verified) comme jamais définissables par le client ; ils ne changent que via des flux dédiés et autorisés.

Une liste blanche est le défaut sûr car tout ce que vous oubliez n'est par défaut pas lié. Une liste noire de champs « interdits » échoue dès que quelqu'un ajoute une nouvelle colonne sensible sans mettre à jour la liste.

Pourquoi les distracteurs sont faux

• Masquer le champ dans le frontend confond l'IU avec l'API. L'attaquant n'utilise pas votre formulaire — il envoie une requête HTTP brute avec le JSON qu'il veut.
• Renommer isAdmin relève de la sécurité par l'obscurité. Les noms de champs fuient via les réponses d'API, les source maps, la documentation et les messages d'erreur, et sont vite devinés ou découverts.
• Ajouter une validation côté client s'exécute dans le navigateur de l'attaquant, qu'il contrôle entièrement ; cela se contourne trivialement avec curl ou un proxy d'interception.

Ce que l'examinateur cherche à évaluer

Si vous reconnaissez que la confiance doit être imposée côté serveur, au niveau de la liaison, savez nommer le motif DTO/strong-params et comprenez pourquoi la liste blanche l'emporte sur les astuces d'IU comme sur les listes noires. Le signe d'une mauvaise réponse est de corriger là où le client peut voir — car le client est précisément celui en qui on ne peut pas avoir confiance.