flawopen.com/Mass assignment/Explicado
Mass assignment: riscos e listas seguras de campos
Imagine um modelo como um formulário com campos do usuário e controles exclusivos da equipe. Vincular toda a requisição deixa o cliente preencher até propriedade, aprovação ou função. Defina os campos editáveis no servidor e autorize registro e operação separadamente.
# 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;
Por que listas permitidas no servidor são importantes
Uma lista de bloqueio como “aceite tudo, exceto role” pode falhar quando surge um novo campo sensível. Com uma lista permitida, novos campos ficam indisponíveis até serem expostos pelo código. No Rails, Strong Parameters rejeitam atributos não permitidos na atribuição em massa; o controlador ainda deve permitir apenas os campos apropriados à ação. DTOs, serializers ou formulários explícitos criam a mesma fronteira.
A lista limita atributos definidos pela requisição, mas não autoriza alterar o registro. Restrinja-o ao usuário autenticado, autorize a operação e reserve mudanças privilegiadas a fluxos separados controlados pelo servidor.
Categorias de campos sensíveis
Revise os atributos do modelo, serializers aninhados e endpoints de atualização:
- ✓Propriedade e tenant — user_id, account_id, tenant_id. Verifique propriedade e autorização no servidor; não confie no proprietário enviado pelo cliente.
- ✓Funções, permissões e estado — role, is_admin, email_verified, status. Altere somente por fluxo autorizado no servidor.
- ✓Valores financeiros e campos aninhados/do sistema — saldos, descontos, créditos, relações, timestamps e IDs podem afetar regras ou ampliar atualizações. Permita e valide cada campo.
Perguntas frequentes
São falhas distintas. Mass assignment define atributos indevidos no objeto criado ou atualizado. Prototype pollution altera propriedades de um protótipo e pode afetar a busca de propriedades por outros objetos. Uma mesclagem insegura pode levar a isso; mass assignment depende de como a aplicação usa as propriedades. Veja prototype pollution.
Não. Uma mutação pode aceitar entrada ampla demais. Limite tipos de entrada aos campos editáveis e autorize objeto e operação no resolver ou serviço.
Não. O formulário não limita o que um cliente HTTP envia. Trate todos os campos como controlados pelo atacante, valide a estrutura no servidor e aceite só os campos previstos para a ação.