How to find the API endpoints that leak other customers' data, without testing a single one.

Why the most common API flaw is still the hardest to find

BOLA is a flaw in logic, not in syntax. The malicious request is identical in shape to a legitimate one; only the owner of the record is different. Firewalls and gateways see nothing unusual, because there is nothing unusual to see.

The standard answer is active testing. A scanner or a penetration tester creates accounts for different users, then tries to reach one user's records from another's session. It works, but it is expensive. Someone has to create and maintain test accounts for every role, keep the API specification current, script the attacks and decide how far it is safe to push them against production. And it only tests what someone thought to test. In a large API that changes every week, the undocumented and legacy endpoints, which are exactly where these flaws hide, are often never tested at all.

The application already knows who owns what

Our starting point is an observation about how applications are built. Most of them get their list pages right. The page that shows “your invoices” or “your documents” almost always filters correctly, because a developer saw it, tested it and would have noticed another customer's data there. The flaw usually lives one step later, on the endpoint that fetches a single item by its number.

Every time the application shows a user their own list, it is telling you, accurately, what that user is allowed to see.

That means the correct parts of an application can serve as the reference for the broken parts. You do not need a specification to know the ownership rules. You need to watch the system behave and measure it. That is a physicist's habit, and it is the idea at the centre of both new modules.

SOTEVIS Map: whose data does each endpoint serve?

SOTEVIS Map reads a mirrored copy of your API traffic beside the gateway and compares, for every endpoint, what the same user receives across sessions with what different users receive. If the same user keeps getting the same items and other users get different ones, that endpoint is filtering by user. If everyone gets the same thing, it is open. If members of the same team get the same thing and other teams get something else, it is shared.

The result is a living inventory of your API that sorts every endpoint as personal, shared or open, with no specification, source code or labels. It also flags the endpoints that hand out many different users' records, such as a search that says too much or an export that returns everyone. For security teams, that is the list of what to test first. For privacy teams, it is a map of where personal data is really served.

SOTEVIS Locate: which endpoints never say no?

SOTEVIS Locate builds on that map. From the endpoints that filter correctly, it learns the set of items each user has legitimately been shown. Then it watches for something that happens in every live application, every day: ordinary users asking for items outside their own set by accident. An old bookmark. A share link that has since been revoked. A mistyped number.

An endpoint with a working ownership check refuses some of those requests. An endpoint without one serves them all. SOTEVIS Locate compares each endpoint's refusal rate with the endpoints that do enforce ownership, and ranks the ones that never say no. The evidence is strongest when the same user and the same item were refused on one endpoint and served on another, because that is the application contradicting itself. Each finding comes with real examples an engineer can replay in a test environment and confirm in minutes.

Staff whose job is to work across accounts, such as support teams, are treated separately so they cannot mask the signal. Endpoints that are open by design, such as a preview, go on an allow-list. Where the traffic does not yet hold enough evidence, SOTEVIS Locate says so rather than guessing.

Why passive changes the economics

Because SOTEVIS Locate sends nothing to your API, there are no test accounts to maintain and no risk to production. Because it learns from real users, it covers every endpoint they touch, documented or not. And because it runs continuously, a check that breaks in next week's release shows up in next week's traffic, not at next year's penetration test.

What we have shown so far

We tested both modules in simulation, in API environments built separately from the detector, each with a hidden set of endpoints missing their ownership check. SOTEVIS Map identified exactly the endpoints that filter by user in every run, while correctly setting aside public feeds, leaky searches and activity streams that change over time. Across 20 environments, SOTEVIS Locate found all 40 vulnerable endpoints from ordinary traffic alone, raised no findings against endpoints that enforced the check, and ranked every vulnerable endpoint above every protected one. The next step is production traffic, and pilots are now open.

Where this fits in SOTEVIS

SOTEVIS is built in three layers that share one picture of who may see what. SOTEVIS Map shows whose data every endpoint serves. SOTEVIS Locate finds the endpoints missing an ownership check. SOTEVIS runtime detection uses the same picture to catch anyone reaching beyond what they are allowed to see while it happens, including an attacker who uses a customer account to imitate the access pattern of staff who legitimately work across accounts. Map and Locate are where every deployment starts: first see your API, then fix its gaps, then watch it.

The approach is patent pending in the UK.

Work with us

We are running pilots with organisations that operate customer-facing APIs, and we license SOTEVIS to API gateway, API security and cloud platform providers who want to offer it to their own customers. If either describes you, we would like to hear from you at physivitis.tech.