Fix Mass Assignment in Helidon

Mass assignment in Helidon occurs when JSON-B or Jackson blindly binds HTTP request bodies to internal POJOs or JPA entities. If your entity contains sensitive fields—like 'role', 'isAdmin', or 'accountBalance'—an attacker can simply append these keys to their JSON payload to escalate privileges. In Helidon MP, this is a common oversight when using JAX-RS resources without strict Data Transfer Objects (DTOs).

The Vulnerable Pattern

@POST
@Path("/update")
@Consumes(MediaType.APPLICATION_JSON)
public Response updateAccount(UserEntity user) {
    // VULNERABLE: Helidon binds the entire JSON body directly to the UserEntity.
    // An attacker sends: {"username": "hacker", "isAdmin": true}
    // Even if 'isAdmin' isn't in the UI, the backend maps it and saves it.
    db.merge(user);
    return Response.ok().build();
}

The Secure Implementation

The fix involves decoupling your API surface from your data model. By using a DTO (Data Transfer Object), you define a strict schema of what the user is allowed to touch. If an attacker tries to pass 'isAdmin': true in the payload, the JSON-B provider will either ignore the field (if configured) or fail to find a matching property in the DTO, ensuring the sensitive internal state remains untouched. Always treat incoming request bodies as untrusted blobs and use explicit mapping to update persistent entities.

public class UserUpdateDTO {
    @JsonbProperty("username")
    public String username;
    // No 'isAdmin' field here, preventing unauthorized binding
}
@POST
@Path(“/update”)
@Consumes(MediaType.APPLICATION_JSON)
public Response updateAccount(UserUpdateDTO dto) {
UserEntity existingUser = db.find(UserEntity.class, currentUserId);
// SECURE: Manually map only the fields that are allowed to be modified by the user
existingUser.setUsername(dto.username);
db.merge(existingUser);
return Response.ok().build();
}