Affectation en masse.

L'affectation en masse se produit lorsque des frameworks (Rails, Spring, ASP.NET, NestJS, Django) mappent automatiquement le JSON ou les champs de formulaire entrants vers les attributs d'un modèle sans liste blanche explicite. L'attaquant ajoute des propriétés supplémentaires — isAdmin, role, balance, tenantId — que le serveur écrit ensuite en base. Le défaut est difficile à repérer en revue de code car l'affectation est implicite : un seul appel update_attributes(params) ou de model-binder masque le fait que tous les attributs sont modifiables. Elle est cataloguée sous CWE-915 et figure dans l'OWASP API Security Top 10 (2019 A6, fusionnée dans API3 « Broken Object Property Level Authorization » en 2023).

L'incident canonique est le piratage de GitHub en mars 2012 par Egor Homakov : parce que le formulaire de clé SSH liait public_key[user_id] sans liste blanche, il a ajouté un champ forgé, rattaché sa clé au compte de l'organisation Rails et poussé un commit sur rails/rails. GitHub a corrigé la faille en quelques heures, et l'épisode a poussé Rails à faire du filtrage attr_accessible — plus tard strong_parameters — le comportement par défaut.

Les mesures d'atténuation incluent des DTO ou des schémas d'entrée explicites, des listes blanches strictes des champs liables, la séparation des attributs strictement internes des modèles liables par l'utilisateur, et des tests négatifs soumettant des clés JSON inattendues.

flowchart TD
  A["Le client envoie du JSON<br/>{name, isAdmin:true}"] --> B[Auto-binder du framework]
  B --> C{Liste blanche explicite<br/>des champs ?}
  C -->|Non — affectation en masse| D[Toutes les clés écrites dans le modèle]
  D --> E[(isAdmin=true<br/>persisté en base)]
  C -->|Oui — DTO / strong params| F[Seuls les champs autorisés sont liés]
  F --> G[(Champs privilégiés ignorés)]