An API spends most of its surface on authorization, and gets it wrong more often than anything else. Authentication answers one question, who are you, and libraries answer it well. Authorization answers a harder one: are you allowed this particular object, this particular function. That answer has to be re-derived on every route, for every identity, against every resource, and there is no library that knows your data model. The check is application logic, written by hand, one endpoint at a time, and a single missing line is a full bypass.

So authorization, not injection or misconfiguration, is where modern APIs leak. The OWASP API Security Top 10 puts broken object level authorization at API1 and broken function level authorization at API5, and breach reports keep describing the same shape: a valid session, a changed identifier, someone else's data. Nothing in the traffic looks like an attack. That is what makes the class dangerous, and what makes it hard to detect.

Broken object level authorization, BOLA, is the API generalization of what web testers long called IDOR, an insecure direct object reference. An endpoint accepts an identifier for an object and returns or modifies that object without confirming the caller is entitled to it.

The whole flaw fits in one line of a request. Signed in, you fetch your own record with GET /api/orders/1043 and the response is your order. You change the identifier and send GET /api/orders/1044 with the same token. If the server returns order 1044, an order that belongs to another account, the object level check is missing. The token proved who you are; nothing proved that order 1044 is yours.

The identifier can live in the path, a query parameter, a request body, or a header, and it does not have to be a sequential integer. A UUID only slows enumeration, it does not add authorization. The defect is not that the id was guessable. It is that the server never asked whether you owned it.

Broken function level authorization, BFLA, moves the gap from the object to the operation. Here the caller invokes a function they should not be able to reach at all: an administrative action, a bulk export, a role change, a method the interface never offered them.

A standard user discovers or guesses a privileged route and calls it directly. Sending POST /api/users/1044/roles with a body of {"role": "admin"} and an ordinary user token, and having the server perform the change, means the endpoint enforced authentication but not authorization for the function.

BFLA also hides in HTTP methods. A read-only user may be blocked from delete in the interface, yet the API still honors DELETE /api/records/1044 when it is sent by hand, because the guard lived in the client rather than the server. Both variants share one root cause: the function trusts that only the right caller would ever reach it, and a real caller proves otherwise.

A signature or pattern scanner cannot find either flaw, and it is worth being precise about why. Static analysis reads source and looks for dangerous constructs: a string concatenated into a query, a secret committed in plain text, a call into a function with a known weakness. Dependency and container scanners match versions and hashes against a database of known-bad. All of them work because the defect is present in the artifact and has a recognizable shape.

Broken authorization has no shape. The vulnerable handler looks correct. It authenticates, it validates input, it uses parameterized queries, it contains no flagged function and no vulnerable dependency. The defect exists only in the relationship between two identities and one object or function, and that relationship does not appear until the code runs and a request arrives.

You cannot pattern-match an absent check. The only way to observe it is to make real, authenticated requests as one principal against another principal's resource, and read what comes back.

Kissaki tests broken object and function authorization by doing exactly that, then keeping the transcript. The method is a controlled two-identity probe. It establishes at least two principals, sends a legitimate request as the first, and records the object identifiers and function routes that identity is entitled to. It then replays those requests as a second, unrelated or lower-privilege identity.

If the second identity retrieves the first one's object, that is a proven BOLA. If it invokes a function reserved for a higher privilege, that is a proven BFLA. The evidence is the pair of exchanges: the exact request that should have been refused, and the response that shows it was not. There is no inference, and no severity attached to a maybe. A finding is raised only when an unauthorized request actually succeeded.

The demonstration is deliberately safe. Probes run against targets the customer has authorized, favor read and idempotent operations, stay within bounds, and do not destroy or exfiltrate data to make the point. The same discipline covers the rest of the surface Kissaki tests over the web and API: mass assignment, business logic flaws, JWT handling, injection and SSRF. Each proven finding carries the reproduction that establishes it.

Authorization is not fixed once. It regresses. A new endpoint ships without the ownership check its neighbors have. A refactor drops a scope comparison. A role is added and the guard that should gate it is forgotten. None of these change a dependency version or trip a signature, so a point-in-time audit that passed last quarter says nothing about the code that merged yesterday.

Kissaki re-runs the same two-identity probes automatically, every 24 hours. Because detection is deterministic, the same input returns the same finding on every run, so a genuine regression surfaces as a finding that closed and then reopened rather than as noise. An authorization gap that was fixed and later reintroduced is caught on the next cycle, with a fresh reproduction, instead of being rediscovered in a breach.

Broken object and function level authorization stay at the top of the API risk list because they are logic, not artifacts. They cannot be read out of source, matched against a database, or inferred from a pattern. They are found the way an attacker finds them, by sending a request as one identity and watching the server answer for another, and they are only worth reporting when that request actually succeeded.

That is the standard Kissaki holds itself to on this class of finding: a real unauthorized request, a real response, attached as proof, re-tested on every cycle. Proof, not guesswork, especially for the flaws no scanner can see.