Most modern products are APIs with interfaces on top. Your web app, your mobile apps, your integrations and your partners all talk to the same endpoints. That makes the API the most direct route to your data and your business logic.
It also means the usual safety nets disappear. There’s no interface hiding a button, no form limiting what can be sent. An attacker talks to the API exactly as your own front end does, and tries everything the front end never would.
This guide walks through the OWASP API Security Top 10 (2023) in plain English, explains how testers look for each risk, and covers what to prepare for an API penetration test.
Why API security needs its own focus
Web application testing has always included the API calls a browser makes. But APIs have grown beyond that:
- More endpoints than any interface uses. Old versions, admin routes and internal endpoints often remain reachable.
- Direct object access. Requests carry IDs for invoices, users and files, and every one of them is a potential authorization check.
- Machine clients. Mobile apps, integrations and partners call APIs in bulk, so rate limits and business-flow controls matter more.
- Many technologies. REST, GraphQL and gRPC each bring their own quirks.
The OWASP API Security Top 10 exists because these risks differ from those in the general web Top 10.
The OWASP API Security Top 10 (2023), explained
The 2023 edition lists ten categories. Here’s what each one means in practice.
| ID | Risk | In plain English |
|---|---|---|
| API1 | Broken Object Level Authorization | You can access a record that isn’t yours by changing its ID |
| API2 | Broken Authentication | Logins, tokens or sessions can be guessed, forged or reused |
| API3 | Broken Object Property Level Authorization | You can see or change fields you shouldn’t, even on your own records |
| API4 | Unrestricted Resource Consumption | Nothing stops requests that are too many, too big or too expensive |
| API5 | Broken Function Level Authorization | You can call functions meant for a more privileged role |
| API6 | Unrestricted Access to Sensitive Business Flows | A legitimate feature can be abused at a scale that hurts the business |
| API7 | Server Side Request Forgery | You can make the server fetch a URL of your choosing |
| API8 | Security Misconfiguration | Defaults, verbose errors, missing headers or permissive CORS |
| API9 | Improper Inventory Management | Old, undocumented or forgotten APIs are still exposed |
| API10 | Unsafe Consumption of APIs | Your API trusts data from third-party APIs too much |
API1: Broken Object Level Authorization
Ranked first by OWASP, and often the most damaging API flaw. A request like GET /api/invoices/1042 returns invoice 1042, but the API never checks that the invoice belongs to the caller. Change the number and you see someone else’s data.
How testers look for it: with accounts in two tenants, they request every object one account owns while signed in as the other, across every endpoint and method.
API2: Broken Authentication
Weaknesses in how the API confirms who you are: tokens that never expire, JWTs whose signatures aren’t verified, password reset flows that can be abused, or login endpoints without protection against guessing.
How testers look for it: by examining token structure and lifetime, tampering with tokens, and testing every authentication-related endpoint, not just login.
API3: Broken Object Property Level Authorization
Even when you may access an object, you may not be allowed to see or change every field. Two classic forms:
- Excessive data exposure: the API returns fields the interface never shows, such as internal flags or other users’ email addresses.
- Mass assignment: the API accepts fields it shouldn’t, so adding
"role": "admin"to a profile update actually works.
How testers look for it: by comparing responses with what each role should see, and by sending extra properties in write requests.
API4: Unrestricted Resource Consumption
APIs without limits on request rate, payload size, page size or expensive operations. This can cause outages, run up infrastructure bills, or make brute-force attacks practical.
How testers look for it: carefully, and within agreed rules of engagement. They check for limits rather than trying to exhaust your systems.
API5: Broken Function Level Authorization
Here the problem is the action, not the record. A regular user can call DELETE /api/users/{id} or /api/admin/export because the endpoint checks that the user is logged in but not that they are an admin.
How testers look for it: by mapping every function available to the highest-privileged role, then calling each one as lower-privileged users.
API6: Unrestricted Access to Sensitive Business Flows
A feature works exactly as designed, but nothing stops it being automated at scale. Think of bulk-buying limited stock, mass-creating accounts to abuse a referral offer, or scraping every listing.
How testers look for it: by identifying the flows that would hurt the business if abused, then checking what limits, if any, apply to them.
API7: Server Side Request Forgery
Features that fetch a URL on the user’s behalf, such as webhooks, imports or link previews, can sometimes be pointed at internal services or cloud metadata endpoints.
How testers look for it: by supplying URLs that target internal addresses and observing how the server responds, using safe, non-destructive payloads.
API8: Security Misconfiguration
A broad category: permissive CORS, verbose error messages that leak stack traces, unnecessary HTTP methods, missing transport security or default settings left on.
How testers look for it: with a mix of tooling and manual review across every environment in scope.
API9: Improper Inventory Management
Version 1 of the API was replaced by version 2, but v1 is still running, without the fixes. Or a staging API with real data is reachable from the internet.
How testers look for it: by looking for undocumented versions, environments and hosts, and checking whether they share data or credentials with production.
API10: Unsafe Consumption of APIs
Your API calls third-party APIs and trusts their responses without validation. If a partner is compromised, or a response is manipulated, your system follows along.
How testers look for it: by reviewing how integration data is used, and where possible by testing how your API handles unexpected responses.
REST, GraphQL and gRPC: what changes
The Top 10 applies whatever technology your API uses, but each one shifts where testers look.
REST
REST APIs expose many endpoints, each with its own URL and method. Authorization has to be enforced on every one, which makes it easy for a single endpoint to be missed. Testers map every route and method combination, including PUT, PATCH and DELETE variants the interface never calls.
GraphQL
GraphQL usually exposes a single endpoint, and clients ask for exactly the data they want. That flexibility moves the risk:
- Field-level authorization matters more, because one query can reach many types and fields at once.
- Introspection, if enabled in production, hands an attacker a full map of your schema.
- Query depth and complexity need limits, or a single nested query can consume large amounts of server resources (API4).
- Batching can let an attacker try many passwords or codes in one request, sidestepping simple rate limits.
gRPC
gRPC services use binary messages defined in protocol buffer files. They’re often treated as internal and assumed to be safe, but if they’re reachable they need the same authentication and authorization as any public API. Testers work from your .proto definitions, which is one more reason to share documentation.
Whatever the technology, the underlying question is the same: does every request get checked against who is asking and what they’re allowed to do?
Why scanners miss the most important API flaws
Automated API scanners are good at known misconfigurations and common injection patterns. They struggle with authorization, because they don’t know your business rules. A scanner sees that GET /api/invoices/1042 returns 200 OK. It can’t tell that the invoice belongs to a different customer.
That’s why API testing is mostly manual. Testers build a picture of who should be able to do what, then check every combination that matters.
What to prepare for an API pentest
- API documentation: an OpenAPI (Swagger) file or a Postman collection. Without one, testers spend time mapping endpoints instead of testing them.
- Credentials for each role, ideally in two separate tenants so cross-tenant access can be tested.
- The base URL of the environment to test, and any data or rate limits to respect.
- Client apps in scope, such as the web or mobile apps that use the API.
- A technical contact for questions during testing.
- An agreed testing window.
What a good API test report includes
For each finding, expect the affected endpoint and method, the roles involved, the request and response that prove the issue, the impact in business terms, and a specific fix. Authorization findings should state which account accessed which object, so your developers can reproduce them in minutes.
After fixes, a retest confirms what is resolved. Our methodology explains how we rate severity, and our sample report shows how findings are presented.
Bringing it together
The OWASP API Security Top 10 is a useful map, but the core message is simple: every endpoint must enforce authorization for every object, property and function, every time. Testing that properly takes accounts for every role, good documentation, and people who understand what your product is meant to allow.
If you’re planning a test, see our API penetration testing service, or try our free scope estimator to size the effort.
Frequently asked questions
What is the OWASP API Security Top 10?
It's a list, maintained by OWASP, of the most significant categories of API security risk. The current edition was published in 2023. It's a widely used reference for designing and testing APIs, not a compliance standard in itself.
Do you test GraphQL and gRPC as well as REST?
Yes. The underlying risks are the same, such as broken authorization and excessive data exposure, but each technology has its own testing techniques, for example GraphQL introspection and query complexity.
Why do you need accounts in two tenants?
The most damaging API flaws let one customer reach another customer's data. Testers can only check that properly with accounts in at least two separate customer accounts.
Is an API pentest different from testing the web app?
A web app test usually covers the API calls the front end makes. A dedicated API test goes further, covering every endpoint, including ones the interface never uses, as well as partner and public APIs.
Can't we just use an API scanner?
Scanners are useful for known misconfigurations and injection checks. But they can't tell whether user A should be allowed to read invoice 42, and that kind of authorization flaw is among the most serious API issues.