Access control & IDOR

A01 has topped the OWASP Top 10 two editions running, and not because it is hard to understand — because it is the bug with no syntactic signature. SQL injection has a quote you can grep for; a missing authorisation check looks exactly like a present one: both are a single FindByIdAsync(id). No linter finds it, no WAF blocks it, and automated scanners are blind to it because catching it requires understanding who ought to read what — that is, your business rules.

From a developer's side, three properties make it recur forever:

• It lives at every endpoint. A new endpoint is a new chance to forget.
• Happy-path tests stay green. Alice reads Alice's order — pass. Nobody writes "Alice reads Bob's order" unless a convention forces them to.
• It decays silently. The endpoint checks ownership today; next month somebody adds an overload "for the internal job" that drops the userId argument.

On impact: no escalation needed, no payload needed. A for loop over id is the entire database, and in your logs it looks like ordinary traffic from a signed-in user.

The mechanism is an omitted question. The system asks "who are you?", then goes straight to the query without asking "is this yours?".

sequenceDiagram    autonumber    actor B as Bob (signed in)    participant API    participant DB    B->>API: GET /api/orders/1042<br/>Authorization: Bearer <Bob's token>    Note over API: ✅ Token valid → Bob is Bob.<br/>❌ Nobody asks whether 1042 is Bob's.    API->>DB: SELECT * FROM orders WHERE id = 1042    DB-->>API: Alice's order    API-->>B: 200 — Alice's address, card last-4, purchase history

The technically important point: the query is where the bug lives, not the middleware. WHERE id = 1042 leaves no seam for middleware to enter. The middleware knows Bob is Bob; it does not know what 1042 is. That is why the correct fix belongs in the query — see block 6.

Four forms, needing four different fixes:

The second form deserves a note: it usually shows up as an undocumented endpoint. The UI hides the Delete button from normal users, so nobody tests the DELETE route — but the route is still there, and Swagger tells anyone who asks.

One endpoint, three requests. The second is the bug; the third is why status codes deserve attention.

# 1 — Bob reads his own order. As designed.GET /api/orders/1041 HTTP/1.1Authorization: Bearer eyJ…bob HTTP/1.1 200 OK{"id":1041,"total":"429000","address":"12 Nguyen Hue, D1"}

# 2 — Bob reads Alice's order. Same token, same endpoint, one digit different.GET /api/orders/1042 HTTP/1.1Authorization: Bearer eyJ…bob HTTP/1.1 200 OK                       ← this is the bug{"id":1042,"total":"1250000","address":"88 Le Loi, D3","cardLast4":"4242"}

# 3 — After the fix. 404, NOT 403.GET /api/orders/1042 HTTP/1.1Authorization: Bearer eyJ…bob HTTP/1.1 404 Not Found{"errorCode":"ER_ORDER_NOT_FOUND"}

Why 404 and not 403: a 403 confirms order 1042 exists. Given a loop over id, the difference between 403 and 404 is a complete map of which orders are real — enough to infer company size, growth rate, and who the large customers are.

First American Financial, May 2019 — 885 million documents. Links to real-estate transaction documents took the form …/DocumentHandler?id=<sequential number> with no authorisation check at all. Anyone holding one valid link could read every other by subtracting 1. The records included bank account numbers, photographed tax IDs, and driving licences. This is IDOR at its purest — no technique, just a loop.

Optus, September 2022 — ~9.8 million Australian customers. An unauthenticated API on a subdomain, with a sequential contactId. The ACMA proceedings state the endpoint was left behind after an infrastructure change. Exactly the lesson from block 2: the endpoint you forget is the endpoint nobody authorises.

Peloton, 2021. The API returned profile data (age, weight, city, workout history) for any userId, including profiles explicitly set to private — among them a sitting US president's. Notable because the first fix merely required being logged in, and any free account could still read everything.

There is really only one check that matters on this topic, and it is the one almost no codebase has: every endpoint taking an id must have a cross-tenant test.

1. The cross-tenant test, as an enforced convention. See the csharp / test tab. Shape: two users in the fixture, and the test asserts user A cannot read user B's, with 404 as the correct status. The crucial part is making it a countable convention — see check 3.

2. Check repository signatures, merge-blocking:

# A repository for a user-scoped entity must not expose a one-argument GetById.grep -rnE 'Task<[A-Za-z]+\??> GetByIdAsync\(([A-Za-z]+Id )?id' \  --include='*Repository.cs' src/ | grep -vE 'userId|tenantId|ownerId' \  && { echo "GetByIdAsync without user scope — blocked"; exit 1; }exit 0

3. Measure authz coverage, not line coverage. Enumerate every route containing {id} from Swagger or EndpointDataSource, cross-reference against tests named *_returns_404_for_other_user. Any route with no matching test fails the build. This is the check that turns "remember to write the test" into "you cannot merge without it":

dotnet run --project tools/AuthzCoverage -- --fail-on-missing

4. Check deny-by-default is intact:

# Every controller sits under the global [Authorize]; each [AllowAnonymous] is listed and reviewed.grep -rn "AllowAnonymous" --include='*.cs' src/ | diff - docs/allowed-anonymous.txt \  || { echo "A new anonymous endpoint appeared without review"; exit 1; }

5. Check RLS actually blocks (layer 2 is easy to believe is on when it is not):

SET app.user_id = '00000000-0000-0000-0000-000000000001';-- Must return 0 even though order 1042 exists:SELECT count(*) FROM core."order" WHERE id = 1042;-- And confirm nobody disabled the policy:SELECT relname, relrowsecurity, relforcerowsecurity FROM pg_class WHERE relname = 'order';

The process mistake, which outweighs every row above: treating authorisation as code review's job. Code review finds bugs present in the diff; a missing authorisation check is a bug absent from the diff. Noticing what is not there is something humans are bad at — so it has to be the job of method signatures and CI.

The scoping mistake: fixing only the reported endpoint. An IDOR on /orders/{id} almost always has siblings at /invoices/{id} and /orders/{id}/items — same author, same habit.