Quiz Entry - updated: 2026.07.14
How do you prevent Mass Assignment vulnerabilities in a web API?
Use allowlists (whitelists) to explicitly define which fields can be updated, and never bind request data directly to internal objects — then a field the form never exposed simply can't be smuggled in.
Vulnerable (Java/Spring):
// DANGEROUS: binds ALL request parameters to User object
@PostMapping("/users")
public User createUser(@RequestBody User user) {
return userRepository.save(user); // isAdmin could be set!
}
Secure — DTO pattern:
// SAFE: only transfers allowed fields
public class CreateUserDTO {
private String username;
private String email;
// isAdmin is NOT here — can't be set
}
@PostMapping("/users")
public User createUser(@RequestBody CreateUserDTO dto) {
User user = new User();
user.setUsername(dto.getUsername());
user.setEmail(dto.getEmail());
user.setAdmin(false); // explicitly set
return userRepository.save(user);
}
| Approach | How it works | Framework example |
|---|---|---|
| DTO/ViewModel | Separate class with only allowed fields | Spring: @RequestBody CreateUserDTO |
| Allowlist | Explicitly list bindable fields | Rails: params.permit(:name, :email) |
| Blocklist | Block sensitive fields (weaker) | Django: exclude = ['is_admin'] |
| Read-only fields | Mark fields as non-writable | Jackson: @JsonProperty(access = READ_ONLY) |
Tip: Always prefer allowlists over blocklists — forgetting to add a new field to an allowlist is safe (field is ignored), but forgetting to add it to a blocklist is dangerous (field is writable).
Go deeper:
OWASP Mass Assignment Cheat Sheet — framework-specific allowlist/DTO implementations (Spring, Rails, Django, Laravel, .NET).