Fix BFLA (Broken Function Level Authorization) in Helidon

BFLA (Broken Function Level Authorization) is the silent killer in microservices. In Helidon, developers often secure the perimeter but forget to gatekeep specific business functions. If an endpoint like '/admin/reboot' is reachable by a low-privilege user just because they have a valid session, your architecture is compromised. Stop relying on 'hidden' paths and start enforcing explicit RBAC at the method level.

The Vulnerable Pattern

@Path("/api/management")
public class ManagementResource {
    @DELETE
    @Path("/user/{id}")
    public Response deleteUser(@PathParam("id") String id) {
        // VULNERABLE: No authorization check. 
        // Any authenticated user can delete any other user if they know the ID.
        db.users().remove(id);
        return Response.noContent().build();
    }
}

The Secure Implementation

To mitigate BFLA in Helidon MP, you must utilize the 'helidon-microprofile-security' dependency. The fix involves three steps: 1. Annotate the resource with '@Authenticated' to ensure the user is who they say they are. 2. Use the JSR-250 '@RolesAllowed' annotation to restrict the specific function to authorized roles. 3. Ensure your 'microprofile-config.properties' correctly maps your Identity Provider's claims (like 'groups' or 'scopes') to Helidon roles. For Helidon SE (Reactive), you must explicitly define these constraints in your Routing rules using the 'SecurityHandler' to intercept requests before they hit your business logic.

@Path("/api/management")
@Authenticated
public class ManagementResource {
    @DELETE
    @Path("/user/{id}")
    @RolesAllowed("ADMIN_ROLE")
    public Response deleteUser(@PathParam("id") String id) {
        // SECURE: Only users with the 'ADMIN_ROLE' scope/role in their JWT can execute this.
        db.users().remove(id);
        return Response.noContent().build();
    }
}