Seven of the top ten API risks are authorization problems a scanner cannot find.
The first entry in the OWASP API list is broken object level authorization, and on the wire it is indistinguishable from a legitimate call with one number changed. Testing for it means understanding what every object represents and who is entitled to reach it. That is human work, and no product on the market does it for you.
- 10 risksIn the published API Security Top 10
- Object levelThe first and most exploited category
- Business flowsA risk category with no technical signature
- InventoryA risk in its own right, ranked ninth
No scanner on earth knows that record 4471 belongs to a different customer.
That one blind spot is the whole reason an assessment surfaces things a year of scanning never did.
- An object-level authorization failure is indistinguishable from ordinary traffic. The method is right, the token is genuine, the body is well formed, and only the identifier belongs to someone else. There is no bad input to catch and no error to raise, because the interface simply answers the question it was asked.
- Property-level problems hide just as well. A response carrying fields this caller has no business seeing is still a valid response. A request that quietly sets a field the caller should never control is still a valid request. Catching either means knowing what the data model was supposed to allow.
- Abuse of a business flow leaves no technical fingerprint whatsoever. Running a process at machine speed that was designed for a person clicking is not a defect in any individual request. The damage lands on the balance sheet rather than in a log, which is precisely why no tool has anything to raise.
- What actually finds them is a person with two accounts, a clear picture of what each object represents, and the patience to walk identifiers one at a time. That work depends on documentation, which is one more reason the standard treats inventory as a risk in its own right.
Why testing an interface is not the same job as testing a website.
Object level authorization is the first risk
Endpoints deal in object identifiers, and every identifier is a door. That produces an enormous surface of object-level access control problems. Editing a number in an otherwise legitimate request is about the least sophisticated attack available, and it still works more often than anything else.
Authentication is often implemented incorrectly
Authentication is often built in ways that let an attacker capture a token, or exploit a flaw in how identity is established to become another user for a while or for good. In practice the weakness almost always turns out to be how tokens are issued, validated, or allowed to expire.
Property level authorization is separate
The third entry combines excessive data exposure and mass assignment, emphasizing the lack of or improper authorization validation at the object property level. An endpoint can be correctly authorized and still return or accept fields it should not.
Resource consumption is a security risk
Every request costs bandwidth, processor time, memory, and storage. Leave that unbounded and an attacker can either take the service down or simply run your bill up, which on consumption-priced cloud infrastructure is an attack with a dollar figure attached.
Function level authorization fails in complex models
Access control built from overlapping hierarchies, groups, and roles, with a fuzzy line between what an administrator can do and what an ordinary user can do, reliably produces authorization defects. Almost every production system we assess has exactly that shape.
Business flows can be abused without any flaw
Here a business process is exposed with no thought given to what happens when a script runs it ten thousand times an hour. No code is defective, every request is legitimate, and the commercial damage is real.
Inventory is a risk category in itself
There are simply more endpoints here than a web application ever had, which puts unusual weight on documentation being both complete and current. Forgotten, undocumented, and deprecated interfaces are a named risk in the standard, not a tidiness problem to get to eventually.
Consuming other APIs carries its own risk
Data arriving from another company API gets treated as trustworthy in a way user input never would, so it is validated less carefully. That inverted assumption is the tenth entry in the standard, and in our experience nobody tests it.
Ten risks, and what each one actually looks like.
Identifier
API1:2023
- Risk
- Broken Object Level Authorization
- What it looks like in practice
- A valid request with somebody else's identifier
Identifier
API2:2023
- Risk
- Broken Authentication
- What it looks like in practice
- Token compromise or assuming another identity
Identifier
API3:2023
- Risk
- Broken Object Property Level Authorization
- What it looks like in practice
- Fields returned or accepted that should not be
Identifier
API4:2023
- Risk
- Unrestricted Resource Consumption
- What it looks like in practice
- Denial of service or a runaway cloud bill
Identifier
API5:2023
- Risk
- Broken Function Level Authorization
- What it looks like in practice
- Regular users reaching administrative functions
Identifier
API6:2023
- Risk
- Unrestricted Access to Sensitive Business Flows
- What it looks like in practice
- Automation of a flow designed for humans
Identifier
API7:2023
- Risk
- Server Side Request Forgery
- What it looks like in practice
- Fetching a remote resource from an unvalidated URI
Identifier
API8:2023
- Risk
- Security Misconfiguration
- What it looks like in practice
- Complex configuration with missed settings
Identifier
API9:2023
- Risk
- Improper Inventory Management
- What it looks like in practice
- Endpoints nobody documented or retired
Identifier
API10:2023
- Risk
- Unsafe Consumption of APIs
- What it looks like in practice
- Trusting third party responses more than user input
Four things that make an API assessment worth commissioning.
We test with real accounts at different privilege levels
A single account proves nothing here, because the entire test is whether one customer can reach another customer records. Having several accounts provisioned before we start is the largest single factor in how good the findings turn out to be.
We enumerate before we test
Inventory is a named risk and the precondition for everything after it. Retired-but-running versions, undocumented endpoints, and test environments answering from the public internet all surface in this phase, and they are frequently the worst things in the report.
We include business flow abuse
The standard covers business flows exposed without any thought for what automation at scale would do to the company. Assessing that requires understanding how the business makes money, and it is the category most testing quietly skips.
We report against stable identifiers
Findings mapped to the published identifiers give developers, security teams, and enterprise customers a shared vocabulary. It also lets you compare assessments over time and across products without translating between report formats, which matters when a SOC 2 auditor or a customer's security team reads it.
Three phases across roughly four to eight weeks.
- 01Weeks 1 to 2
Inventory and understand
Every endpoint in every version and every environment, what each one exposes, how authorization was meant to work, and which flows carry commercial weight. Documentation quality is assessed here too, because inventory is itself one of the named risks.
- Endpoint inventory across versions and environments
- Object and property model documented
- Intended authorization model captured
- Sensitive business flows identified
- 02Weeks 3 to 6
Test authorization properly
Authorization gets tested at the object, the property, and the function level, using several accounts sitting at different privilege levels. This phase is where the findings come from, and it resists automation entirely because it rests on knowing what ought to be allowed in the first place.
- Object level authorization tested per endpoint
- Property level exposure and mass assignment tested
- Function level separation tested across roles
- Findings evidenced with reproducible requests
- 03Weeks 7 to 8
The remaining categories and the report
How authentication and tokens behave, whether consumption is bounded, how business flows hold up under automation, whether user-supplied URLs can be turned against your own network, per-environment configuration, and how safely you consume other people interfaces. The report is then organized around the standard identifiers.
- Authentication and token handling assessed
- Rate and resource limits tested
- Business flow abuse scenarios exercised
- Report structured by the published risk identifiers
Six situations that prompt an assessment.
A SaaS company whose product is mostly API
When the interface is the product, its security is the product security. Testing that treats it as plumbing behind a front end misses the surface your customers actually call, and the one attackers reach for first. Enterprise buyers have caught on, and their questionnaires now ask about this specifically rather than about application testing generally.
A fintech exposing financial data interfaces
Financial interfaces draw knowledgeable attackers and equally knowledgeable reviewers, whether that is a banking partner, a GLBA examination, or an FTC Safeguards assessment. Authorization across nested account hierarchies is precisely the complex access control the fifth risk describes, and it does not get tested by accident.
A business suffering automated abuse
Mass account signups, inventory held in carts to starve real buyers, promo codes guessed at machine speed, and wholesale scraping are all abuse of a working feature rather than exploitation of a broken one. The standard names them as their own risk, which is what makes them something you can actually assign and fix.
An organization with an unexplained cloud bill
Unbounded consumption produces either an outage or a bill. When cloud spending climbs without a business reason anyone can point at, an endpoint with no limits on it is a genuinely plausible explanation and worth testing before the next invoice.
A team that has accumulated API versions
Any version that was never properly retired is still attack surface, and by definition it gets less attention than whatever the team is shipping now. Walking through versions and environments routinely uncovers interfaces the current engineers had no idea were still answering.
A product that integrates several third party services
Responses from another company interface get trusted in a way user input never is, and validated to a lower standard as a result. If your product consumes payment, identity, shipping, or data-provider responses, that assumption is worth putting under pressure.
How US organizations test their APIs.
| Feature | Manual assessment against the list | Automated scanning only | Tested as part of the web app |
|---|---|---|---|
Object level authorization tested | Yes, with multiple accounts | No | Rarely |
Property level issues found | Yes | No | No |
Function level separation tested | Yes | Partially | No |
Business flow abuse considered | Yes | No | No |
Full endpoint inventory produced | Yes | Crawled only | Partial |
Old versions included | Yes | If discovered | No |
Third party consumption assessed | Yes | No | No |
Findings reproducible | With exact requests | Tool output | Varies |
Maps to a published risk list | Yes | Loosely | No |
Effort | Weeks, mostly manual | Hours | Included, superficially |
Ninth in the standard, first in every engagement we have run.
An endpoint nobody knows about cannot be assessed, defended, or switched off. That makes this the prerequisite for doing anything about the other nine.
- The standard puts it plainly: there are more endpoints here than a web application ever had, which makes accurate and current documentation unusually important. Counts in the hundreds are entirely normal, and complete documentation almost never is.
- Old versions are the textbook example. Shipping version two rarely means retiring version one, because some integration partner somewhere is still calling it. From that day forward version one gets none of the attention version two receives, while continuing to hand out the same data behind older, weaker controls.
- The other classic is everything that is not production. Staging and test interfaces routinely hold real customer data behind visibly weaker authentication, and they are reachable from the public internet far more often than the teams running them believe.
- Every engagement opens here, for entirely practical reasons. Establishing what exists across versions and environments is what defines the scope of all the later work, and it reliably turns up interfaces that nobody in the kickoff meeting knew were still serving traffic.
Five phases, of which the middle three cannot be automated.
- 1
Enumerate the API estate
We enumerate every endpoint across every version and environment, because there are far more of them here than in a web application and the documentation is rarely complete. Anything undocumented or deprecated is written up as a finding rather than a footnote.
- 2
Understand the intended authorization model
We establish what each object actually is, who should be able to read it and who should be able to change it, which fields are sensitive, and exactly where administrative capability is supposed to stop. You cannot test authorization without first knowing what correct behavior looks like.
- 3
Test object, property, and function level authorization
Using several accounts at different privilege levels, we walk identifiers, try to set fields that should be off limits, and reach for functions that should be separated from ordinary users. These three categories account for the majority of findings in almost every engagement.
- 4
Cover the remaining categories
Then authentication and token behavior, whether consumption has limits, sensitive business flows driven at machine speed, forged server-side requests wherever your code fetches a remote resource, configuration checked per environment, and how you handle what other providers send back.
- 5
Report against the published identifiers
Every finding carries its standard identifier, the exact request needed to reproduce it, and a priority based on how exploitable it is and what it would cost you, not on where its category happens to sit in the list. That structure is what lets a developer be assigned the work and a manager measure whether it got done.
What organizations ask about API security assessment.
Fifteen questions to ask your development team.
Inventory
- How many endpoints do we expose?An exact number.
- Which old versions are still live?Usually more than expected.
- Are staging APIs internet reachable?Often, unintentionally.
- Is the documentation current?A named risk category.
- Who owns each endpoint?Retirement needs an owner.
Authorization
- Is object ownership checked every request?The first risk.
- Can a user set fields they should not?Mass assignment.
- Do responses include hidden fields?Excessive exposure.
- Are admin functions separated clearly?Function level risk.
- Have we tested with two real accounts?The essential test.
Everything else
- Are there rate and size limits?Resource consumption.
- Could a business flow be automated?A distinct risk.
- Do we fetch user supplied URIs?Server side request forgery.
- Do we validate third party responses?The tenth risk.
- Is configuration reviewed per environment?Misconfiguration.
Put one question to your engineers: how many endpoints do we expose, counting old versions?
Then hold that number against what a proper enumeration turns up. The standard names inventory as a risk for a reason, and the distance between those two figures is usually where the serious findings are sitting.
Related Services
Explore more solutions that work great with this service
Penetration Testing
Penetration testing for US businesses across external, internal, web
Learn moreVulnerability Assessment
Vulnerability assessment for US businesses across external attack
Learn moreZero Trust Architecture Assessment
Your architecture measured against NIST SP 800-207
Learn moreSOC 2 Readiness
Get audit-ready for the report your buyers ask for
Learn moreMicrosoft Defender
Advanced endpoint and email threat protection
Learn more