Fix BOLA (Broken Object Level Authorization) in Dropwizard

BOLA (formerly IDOR) remains the #1 vulnerability in the OWASP API Security Top 10. In Dropwizard, the exploit is trivial: an attacker swaps a resource ID in the URL and accesses data belonging to another user because the backend validates the session but fails to validate object ownership. To kill BOLA, you must enforce authorization at the data access layer using the authenticated Principal.

The Vulnerable Pattern

@GET
@Path("/{orderId}")
@UnitOfWork
public Order getOrder(@Auth User user, @PathParam("orderId") Long orderId) {
    // VULNERABILITY: We check if the user is authenticated (@Auth),
    // but we fetch the order solely based on the path parameter.
    // Any logged-in user can access any orderId.
    return orderDAO.findById(orderId)
        .orElseThrow(() -> new NotFoundException("Order not found"));
}

The Secure Implementation

The fix shifts authorization from the application logic to the data query itself. By updating the DAO to include a 'userId' constraint (e.g., SELECT * FROM orders WHERE id = ? AND user_id = ?), you eliminate the possibility of ID harvesting. Even if an attacker guesses a valid orderId, the query will return null because the user_id won't match the session's Principal. Always return a generic 404 or 403 to prevent resource enumeration.

@GET
@Path("/{orderId}")
@UnitOfWork
public Order getOrder(@Auth User user, @PathParam("orderId") Long orderId) {
    // FIX: Scope the query to both the resource ID and the authenticated user's ID.
    // This ensures the database only returns the record if the user owns it.
    return orderDAO.findByIdAndUserId(orderId, user.getId())
        .orElseThrow(() -> new ForbiddenException("Access Denied or Resource Not Found"));
}