API Security: Finding the Paths Attackers Actually Use

Picture a customer portal with an order-status endpoint. A logged-in user opens their order and the app calls an endpoint that takes an order number. The token is valid. The request is well formed. The gateway lets it through and the web application firewall sees nothing unusual. Now change the order number by one digit and the API returns someone else’s order.

That is a hypothetical, but it is the most common shape of API failure, not an edge case. OWASP’s API Security Top 10 puts broken object level authorization first. The flaw is not a malformed payload that a filter can spot. It is a legitimate request to an endpoint that fails to check whether this caller may see this object.

It explains why API security programs that lean on gateways and scanners find plenty of noise and miss the paths attackers use. Those paths are rarely clever. They are the ones nobody inventoried, or the ones that work exactly as designed for the wrong person.

The paths attackers actually take

Reading the OWASP list as a map of attacker behavior, six patterns do most of the work. The table sets each against why existing controls miss it and what finds it.

OWASP’s list also names unsafe consumption of other APIs, server-side request forgery and security misconfiguration. They matter, but the patterns above are where defenders most often find they have no coverage.

Why the gateway is not the answer

A gateway is good at what it does: authenticating callers, enforcing rate limits, terminating TLS, validating schemas. Authorization is different. Whether user A may read order 88 is business logic, and it lives in the service that owns the data. A gateway cannot know that rule unless someone has encoded it, and they rarely have.

There is a coverage problem too. Gateway-based inventories list the APIs that were routed through the gateway. Attackers do not respect that boundary. Services exposed directly through a load balancer, an older version left running after a migration, and endpoints created by a team that never registered them all sit outside the view. A program that starts from the gateway console starts from an incomplete picture.

The practical consequence: discovery has to come from several sources at once. Traffic observed at the edge and load balancers, cloud configuration, source repositories and API specifications, and the client applications themselves. Where those sources disagree, the disagreement is the finding.

Testing that matches how attackers work

Automated scanners are good at injection patterns and misconfigurations. They are poor at ownership logic, because they do not know which records belong to which user. Finding object-level flaws needs test accounts in at least two tenants or roles, and a tester who tries to cross between them.

That makes this a good fit for the pipeline as well as for periodic penetration tests. Write an authorization test for each object type: user A creates a record, user B requests it by identifier and must be refused. It is cheap, it fails loudly, and it catches regressions when a developer adds a new endpoint or a refactor drops a check.

Penetration testing and attack path analysis add the next question: what does this API reach once it is abused? An endpoint that returns customer records is bad. An endpoint that does so and runs with a cloud role that can read the whole storage account is worse. Chaining the API weakness to the identity and data behind it is what turns a finding list into a ranked risk.

Detection and response signals

Object-level abuse leaves a recognizable trace if anyone looks for it. A single token requesting sequential or widely varied identifiers. A rise in not-found and forbidden responses from one client. An account reading far more distinct objects than any normal user. Few teams have these queries ready, because API logs are often kept for debugging, not for investigation, and may not record who asked for what.

Reducing what a successful abuse returns matters as much. Responses that return whole objects and let the front end choose fields hand attackers everything. Returning only what the caller needs limits damage when an authorization check does fail.

Where to spend effort first

• Build an inventory from more than one source and name an owner for every API, including the old ones.

• Retire old versions deliberately. Unused is not the same as unreachable.

• Test authorization per object type in the pipeline, with multiple users and roles.

• Log enough to investigate: caller identity, object requested, outcome. Alert on enumeration patterns.

• Trim responses to the fields each role needs.

• Scope and rotate API credentials, and treat leaked ones as compromised, not as cleanup items.

Leaders deciding where application security money goes can use one question to test their current approach: if an attacker held a valid low-privilege account in your busiest API, what could they read that belongs to someone else? If nobody can answer with evidence, the program is measuring activity, not exposure. Closing that gap is where application security decisions should start.

Sources

• OWASP. API Security Top 10, current edition

• OWASP Cheat Sheet Series. Secrets Management Cheat Sheet (token and key handling)