Fix Mass Assignment in Dropwizard

Mass Assignment in Dropwizard occurs when Jackson automagically maps incoming JSON to POJOs without field-level restrictions. If your Resource methods consume internal entities directly, an attacker can overwrite sensitive fields like 'role', 'is_admin', or 'account_balance' by simply adding them to the JSON payload. This is a classic 'overposting' vulnerability that bypasses business logic.

The Vulnerable Pattern

public class UserEntity {
    public Long id;
    public String username;
    public String role; // Vulnerable: attacker can send {"role": "ADMIN"}
}
@POST
@Path(“/profile”)
public void updateProfile(UserEntity user) {
// DANGER: Jackson maps all matching JSON keys to the entity fields
db.save(user);
}

The Secure Implementation

The fix requires a 'Deny by Default' posture. First, decouple your API contract from your database schema by using Data Transfer Objects (DTOs). Second, leverage Jackson's Access.READ_ONLY annotation on sensitive fields to ensure they are never populated from an incoming request body. Finally, never save a deserialized object directly to the database; always fetch the existing record and manually update the whitelisted fields to maintain a hard boundary between untrusted input and your persistence layer.

public class UserUpdateDTO {
    @JsonProperty("username")
    private String username;
// Force the field to be output-only; Jackson will ignore it during deserialization
@JsonProperty(value = "role", access = JsonProperty.Access.READ_ONLY)
private String role;

public String getUsername() { return username; }
}
@POST
@Path(“/profile”)
public Response updateProfile(@Valid UserUpdateDTO dto) {
UserEntity entity = db.findById(currentUserId);
// Explicitly map only the allowed fields
entity.setUsername(dto.getUsername());
db.save(entity);
return Response.ok().build();
}