LOGBOOK

HELP

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:

From Quiz: SPRG / OWASP Top 10 | Updated: Jul 14, 2026