flawopen.com/Mass assignment /Explications
Mass assignment : risques et listes de champs autorisés
Imaginez un modèle comme un formulaire avec des champs utilisateur et des commandes réservées au personnel. Lier toute la requête permet au client de renseigner aussi la propriété, l’approbation ou le rôle. Définissez les champs modifiables côté serveur et autorisez séparément enregistrement et opération.
# Rails: request keys reach model attributes User.new(params[:user]) // Node / Mongoose: request object used as update await User.findByIdAndUpdate(id, req.body); // Express + Sequelize: request object used as create values await User.create(req.body); # Django: request keys passed as model fields User.objects.create(**request.POST.dict())
# Rails — permit only user-editable fields attrs = params.require(:user).permit(:name, :email) user = User.new(attrs) // Node — construct an allowlisted update const { name, email } = req.body; await User.findByIdAndUpdate(id, { name, email }); # Django — explicit ModelForm fields class UserForm(ModelForm): class Meta: model = User fields = ["name", "email"] // .NET — bind a DTO, then map explicitly user.Name = input.Name; user.Email = input.Email;
Pourquoi les listes autorisées côté serveur sont essentielles
Une liste d’exclusion telle que « tout sauf role » échoue si un nouveau champ sensible apparaît. Avec une liste autorisée, les champs nouveaux restent fermés jusqu’à leur exposition explicite. Rails Strong Parameters rejette les attributs non autorisés lors de l’affectation en masse, mais le contrôleur doit limiter les champs à l’action. DTO, sérialiseur ou formulaire explicite créent la même frontière.
La liste limite les attributs définis par la requête, sans autoriser la modification d’un enregistrement. Limitez celui-ci au principal authentifié, autorisez l’opération et séparez les changements privilégiés.
Catégories de champs sensibles
Vérifiez les attributs de modèle, sérialiseurs imbriqués et points de terminaison de mise à jour :
- ✓Propriété et tenant — user_id, account_id, tenant_id. Vérifiez la propriété côté serveur et ne faites pas confiance au client.
- ✓Rôles, permissions et état — role, is_admin, email_verified, status. Modifiez-les via un workflow serveur autorisé.
- ✓Valeurs financières et champs imbriqués/système — soldes, remises, crédits, associations, horodatages et identifiants peuvent affecter les règles métier ou élargir la mise à jour. Autorisez et validez chaque champ.
Questions fréquentes
Ce sont des failles distinctes. Le mass assignment définit des attributs inattendus sur l’objet créé ou modifié. La prototype pollution modifie des propriétés de prototype et peut affecter la recherche des autres objets. Une fusion dangereuse peut y conduire ; l’effet mass assignment dépend de l’usage des propriétés. Voir prototype pollution.
Non. Une mutation peut accepter une entrée trop large. Limitez les types aux champs modifiables et autorisez objet et opération dans le résolveur ou service.
Non. Le formulaire ne limite pas un client HTTP. Traitez les champs comme contrôlés par l’attaquant, validez-les côté serveur et n’acceptez que ceux de l’action.