La Mass Assignment (o over-posting, auto-binding) nasce da una comodità dei framework: molti mappano automaticamente i campi JSON della richiesta sugli attributi dell'oggetto (utente.nome = body.nome, e così via, per tutti i campi). Comodo... e pericoloso, se non filtri: l'attaccante aggiunge alla richiesta un campo che non doveva poter impostare.
L'esempio classico: la registrazione accetta {"email": "...", "password": "..."} – e l'attaccante manda {"email": "...", "password": "...", "ruolo": "admin"} o {"is_admin": true}. Se il codice fa il binding automatico di tutti i campi ricevuti sull'oggetto utente, si è appena auto-promosso amministratore. La stessa idea vale per impostare l'ID di un altro utente, cambiare un saldo, saltare validazioni.
Le difese:
- allowlist esplicita dei campi accettabili per ogni operazione ("da questa richiesta accetto solo nome ed email") – mai il binding cieco di tutto ciò che arriva
- DTO/schema separati per input e per modello di dati: l'input dell'utente non tocca direttamente l'entità del database
- validazione dei payload rigorosa – è parente dei controlli di sanificazione sull'input
È nella OWASP API Security Top 10 insieme a BOLA, e la radice è la stessa: fidarsi dell'input del client. La regola d'oro dell'appsec – ogni input è ostile finché non dimostrato innocuo – qui significa: decidi tu quali campi accettare, non lasciarlo decidere a chi manda la richiesta.