An alternate-key lookup still needs object authorization

Most BOLA writeups show GET /orders/{id} with a guessed UUID. The same bug often hides behind a “friendlier” lookup: GET /orders?email=, findByExternalId, or where slug = ?.

If the handler resolves a row by email, SKU, username, or external id and returns it whenever some row matches — without proving the authenticated subject may access that row — you still have broken object authorization. Opaque primary keys were never the real control. The missing check was can(user, action, resource) after resolution.

Patterns that hold up:

1. Resolve by alternate key, then authorize the loaded resource for this subject (tenant, ownership, relationship). Do not treat “we found a row” as “they may see it.
2. Keep list/search and single-resource paths consistent. If GET /orders is scoped to the caller’s tenant, GET /orders/by-email must use the same scope — not a privileged global unique index.
3. Prefer the same denial shape as your id-based routes (often 404) so alternate keys do not become an existence oracle across tenants.
4. Log the resolved resource id on deny. “email lookup failed” without the object id makes incident review guesswork.

Quick check: as user A, request user B’s order via email or external id. If it returns, your gate was “row exists, not authorization.

Lookups are convenience. Authorization is still about the object, not the key shape.