BOLA is consistently the most common critical finding in modern APIs, and automated tools are structurally unable to catch it. Here's the manual approach that does.
Broken Object-Level Authorization (BOLA) remains the single most reported critical issue across the API engagements I run, year over year. It is also one of the least likely findings to surface from automated scanning, because the request itself is almost always syntactically valid — the failure is purely in who was allowed to make it.
A scanner sees a 200 response and a well-formed JSON body and moves on. It has no concept of 'this token belongs to user A, and this resource belongs to user B.' That distinction only exists if a human — or a very deliberately configured test harness — is tracking identity across requests and deliberately trying resource IDs that don't belong to the authenticated session.
The manual testing approach I use starts by mapping every endpoint that accepts an identifier: order IDs, invoice numbers, internal UUIDs, even sequential integers. For each one, I test with two authenticated sessions of different privilege and confirm — explicitly — whether object-level checks exist independent of the route's authentication check. Authentication answers 'who are you.' Authorization has to separately answer 'should you see this specific object,' and it's that second question teams consistently under-test.
For engineering teams, the fix is rarely complicated once found: a middleware-level ownership check, consistently applied, closes most of these. The hard part is finding every place it's missing before someone else does.