Automated scanners reliably report injection findings and outdated-dependency findings, but they mostly miss the case where an authenticated request returns a record belonging to a different customer — which is exactly the shape the OWASP Top 10 ranks first by incidence. Explain the testing-theory property that separates those categories, and what it implies about how the Top 10's own numbers should be read.

## What an oracle is In testing theory, an **oracle** is whatever lets you decide that an observed behaviour is wrong. Running the system produces an observation; the oracle turns that observation into a verdict. Without one you can execute a program forever and learn nothing, because you have no basis for calling any output a defect. Security categories differ enormously in how strong their oracle is, and that single property — not how serious the bug is, not how common it is — determines whether tooling can find it. ## Categories with an intrinsic oracle Some defect classes carry their verdict with them. - **Injection.** The invariant is universal: attacker-supplied data must never be lexed as part of an interpreter's grammar. If a probe changes the *structure* of a query, a command line or a document rather than only its values, that is wrong for every application in every domain. The observation is self-evidencing — no knowledge of the business is needed. - **Vulnerable and outdated components.** Decidable from an inventory plus a public advisory database. A version string either falls in an affected range or it does not. - **Security misconfiguration** in its mechanical forms — a missing cookie attribute, a permissive cross-origin policy, a debug endpoint, a default credential. The response or the config file is the evidence, and the rule is application-independent. These are the categories where a scanner is genuinely useful, and unsurprisingly they are the categories whose findings dominate automated reports. ## Why broken access control has no intrinsic oracle Now take the request that returns another customer's order. It was authenticated. It was routed to the correct handler. It executed a syntactically correct query. It returned a schema-valid body with status 200. Every layer behaved exactly as written. The only thing wrong is that *this* principal should not have received *that* resource — and "should not" is a statement about ownership, tenancy, role, delegation, purchase or workflow state. None of that appears in the HTTP exchange, and none of it is derivable from the code, because the code is precisely what omitted it. Two byte-identical exchanges can be a legitimate feature in one application (a support agent reading any order) and a breach in another. The verdict lives in the domain, not the artefact. A useful contrast: a spellchecker flags *teh* without knowing what you meant, but cannot flag *form* written where you meant *from*. Both are valid words; only intent decides. Access control is the second kind of error. ## A defect of absence There is a second, compounding property. Injection is something you **wrote** — a concatenation exists somewhere, at a line number. Broken access control is usually something you **did not write**: the check that was never added to a new endpoint, the ownership predicate missing from one of four read paths, the bulk export that bypasses the guarded handler. The CWE naming captures it directly — *missing authorization* is a distinct weakness from *incorrect authorization*. Missing code has no location. Reviewers and static analysers both work by examining artefacts that exist; an omission presents no artefact to examine. Combine that with ordinary software evolution — an endpoint duplicated for a mobile client, a report bolted onto a legacy service — and omission becomes the steady-state failure mode rather than an unlucky one. ## What the incidence number actually measures Here is the consequence that matters for reading the taxonomy. Not all access-control failures are undecidable: a completely unauthenticated endpoint returning data, a directory listing, a token accepted with its signature unverified — these have oracles, because *no* domain rule permits them. Tools do find those. So the measured incidence for the category is drawn largely from its decidable subset plus whatever human-assisted testing contributed. Which means the number is a floor, not an estimate. The category tops the incidence tables *despite* the measurement being partly blind to its dominant shape, which makes the true rate higher than reported, not lower. Anyone who reads Top 10 percentages as prevalence has inverted the argument. ## The consequence for the list itself The Top 10 is compiled from contributed testing data across a large application population, and incidence is defined as the share of tested applications with at least one instance of a mapped weakness. That method inherits the bias described above: it can only count what current testing detects. The list's authors handle this explicitly by filling a minority of the slots from a practitioner survey instead of from the data — categories the community judges important but that the data cannot yet see well. Those slots are a deliberate patch for measurement blindness. That is the taxonomy-level reading: the Top 10 is a *risk-awareness* ranking assembled from imperfect telemetry, not a measurement of your application. Treating a category's position as evidence of its true prevalence, or treating a clean scan as evidence that a category is absent, both mistake the instrument for the phenomenon.