Fix BOLA (Broken Object Level Authorization) in Helidon

BOLA (Broken Object Level Authorization) remains the top threat in the OWASP API Security Top 10. In the Helidon ecosystem, this vulnerability typically manifests when developers assume that an authenticated user is authorized to access any resource by its ID. If your JAX-RS resource takes a @PathParam and hits the database without verifying that the current SecurityContext principal owns that specific record, you are vulnerable. Exploitation is trivial: an attacker simply increments an ID to scrape your entire backend.

The Vulnerable Pattern

@GET
@Path("/invoice/{id}")
@Authenticated
@Produces(MediaType.APPLICATION_JSON)
public Response getInvoice(@PathParam("id") String id) {
    // VULNERABILITY: Only checks if user is logged in, not if they own the invoice
    Invoice invoice = invoiceRepo.findById(id);
    if (invoice == null) {
        return Response.status(Status.NOT_FOUND).build();
    }
    return Response.ok(invoice).build();
}

The Secure Implementation

The fix involves three critical steps: 1. Injecting the Helidon SecurityContext into the resource method. 2. Retrieving the authenticated user's identity (Subject/Principal). 3. Implementing a hard check that compares the resource's owner attribute against the authenticated user's ID. In high-security environments, this check should be pushed down into the repository layer (e.g., 'SELECT * FROM invoices WHERE id = ? AND owner_id = ?') to ensure authorization is enforced at the query level, preventing any accidental data leakage.

@GET
@Path("/invoice/{id}")
@Authenticated
@Produces(MediaType.APPLICATION_JSON)
public Response getInvoice(@PathParam("id") String id, @Context SecurityContext sec) {
    // FIX: Extract the principal from the SecurityContext
    String currentUserId = sec.userName();
Invoice invoice = invoiceRepo.findById(id);

// Validate existence AND ownership in a single logical check
if (invoice == null || !invoice.getOwnerId().equals(currentUserId)) {
    // Return 404 or 403. 404 is often preferred to prevent ID enumeration/leaking existence.
    return Response.status(Status.NOT_FOUND).build();
}

return Response.ok(invoice).build();
}