Home / Knowledge hub / Ownership check
Knowledge hub
Ownership check
Confirming that the record being requested belongs to the account asking for it.
What it means
An ownership check is the step in your code that asks, before a record is returned or changed, whether that record belongs to the account making the request. The request names an invoice, an order or a file. The check decides whether this account is entitled to that one.
It is separate from signing in. Authentication tells the server who is asking. The ownership check compares that identity with the record's owner, or with the organisation that owns it. Leave the comparison out and any signed-in account can ask for any record.
Why it matters
A missing ownership check is how one customer ends up reading another customer's data. The page works, the login works, and the tests pass, because the tester only ever opened their own records. The flaw sits quietly until someone changes a number in a URL.
The result is a data breach with no exploit in the usual sense, only ordinary requests. That makes it hard to spot in logs and hard to explain to customers, auditors and the regulator who asks how it was possible.
How it shows up
You meet it in every route that takes an identifier: /orders/1042, /api/files/9, a download link, a delete button. The safest pattern is to build the owner into the query itself, so the lookup is for "order 1042 belonging to this account" and returns nothing otherwise.
The mistakes repeat. The check exists on the page that lists records but not on the endpoint that fetches one. It covers reads but not updates or deletes. It trusts an owner field sent in the request body. Test by asking for a record belonging to a different account and see what comes back.
Questions people ask
Ownership check, answered
Is an ownership check the same as authorisation?
It is one part of it. Authorisation covers what an account may do, such as whether it can refund. The ownership check covers which records it may do it to.
You normally need both. Being allowed to view invoices does not mean being allowed to view every customer's invoices.
Which flaw appears when the check is missing?
The usual name is IDOR, or in API terms BOLA. Both mean a record can be reached by supplying its identifier, without proof that it is yours.
OWASP ranks broken object-level authorisation first in its API Security Top 10.
Do random, unguessable IDs replace the check?
No. Long random identifiers make records harder to find, but they leak through emails, logs, shared links and browser history. Anyone who gets one can use it.
Treat unguessable IDs as a second layer. The ownership check is still the control.
Where should the check live?
On the server, as close to the data as you can put it, and in one shared place rather than copied into each route. Checks written separately in fifty handlers will eventually be missed in one.
Checks in the browser or the mobile app do not count, because the caller can skip them.
How do we test for missing ownership checks?
Sign in with two ordinary accounts that should not see each other's data. Take a request from the first, swap in an identifier belonging to the second, and see whether the data comes back.
Repeat for reads, edits and deletes, and for every route that takes an identifier.
Related
Terms that sit next to this one
Object-level authorisation
Checking access to each individual record, not only to the type of record.
BOLA
An API returns a record just because you asked for it by number.
IDOR
Changing an id in a request and getting back someone else's record.
Cross-account access
One signed-in account reaching another account's data or functions.
Server-side authorisation
Enforcing permissions on the server, because hiding a button in the page protects nothing.
Whose record is this, really?
We check cross-account access: whether one signed-in account can read or change another's records. Each finding carries the request and response that proved it, and the line of code in white-box mode. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.