OWASP API Security Top 10

Most QA engineers know the OWASP web Top 10 by heart: SQL injection, XSS, broken access control. APIs break in different ways though, and the general web list misses most of it. OWASP publishes a separate API Security Top 10 because APIs expose business logic directly, often with weaker guardrails than the web pages sitting in front of them.

If your test suite only checks status codes and response shapes, you are validating the contract while missing the risks that actually get companies breached. This guide walks through the 2023 list, what each risk looks like in practice, and where it connects to the schema validation work you may already be doing in api-testing-and-schema-validation.

Why APIs need a separate list

Web app testing focuses on what a browser renders: forms, cookies, session state, and how the DOM handles untrusted input. APIs skip most of that. A client sends a request, the server trusts a token, and business logic runs directly against the database. There is no rendering layer to sanitize anything.

This means an API can be functionally perfect, every field validated and every schema respected, while still leaking another user's data because the authorization check was never wired in. That gap is exactly what the OWASP API Security Top 10 targets.

The ten risks, in plain terms

API1: Broken Object Level Authorization (BOLA). The most common and most damaging API flaw. An endpoint like /orders/{id} returns whatever order matches the ID, without confirming the requester owns it. Change the ID, get someone else's data.

API2: Broken Authentication. Weak token generation, missing expiry, or endpoints that skip auth checks entirely because they were assumed to be internal-only.

API3: Broken Object Property Level Authorization. Similar to BOLA but at the field level. A user can view their own profile but the response includes an isAdmin field they should never see, or can write to.

API4: Unrestricted Resource Consumption. No limits on request size, pagination, or rate. A single query can pull the entire dataset or trigger a denial of service.

API5: Broken Function Level Authorization. A regular user can call an admin-only endpoint because the server checks the token exists but not what role it holds.

API6: Unrestricted Access to Sensitive Business Flows. No protection against automated abuse of legitimate features, like a bot buying out inventory through the checkout API.

API7: Server Side Request Forgery (SSRF). An API that fetches a URL supplied by the client, allowing an attacker to reach internal services that were never meant to be exposed.

API8: Security Misconfiguration. Verbose error messages, default credentials, permissive CORS, or debug endpoints left enabled in production.

API9: Improper Inventory Management. Old API versions and undocumented endpoints stay live and unmonitored, often with weaker protections than the current version.

API10: Unsafe Consumption of APIs. Trusting data from third-party APIs without validating it, treating it as safe just because it came from a partner integration.

If your team can only test one thing this quarter, test BOLA. It accounts for the largest share of real-world API breaches, and it is the easiest risk to check systematically. Take any authenticated endpoint, swap the resource ID for one owned by another test account, and confirm the request is rejected. Do this across every resource-scoped endpoint before moving to the rest of the list.

A worked example: testing for BOLA

Say your app has GET /api/invoices/{invoiceId}. As QA, set up two test accounts, A and B, each with their own invoice. Log in as A, capture a valid token, and note B's invoice ID from a separate session. Then send GET /api/invoices/{B_invoice_id} using A's token.

A correctly authorized API returns 403 or 404. A vulnerable one returns B's invoice data. Automate this check for every object-scoped endpoint in your suite, not just the obvious ones like user profiles. This is complementary to contract testing: schema validation confirms the response shape is correct, but it says nothing about whose data ended up in it.

```
// pseudo-test: BOLA check on invoice endpoint
test('user A cannot fetch user B invoice', async () => {
const res = await api.get(/api/invoices/${userB.invoiceId}, {
headers: { Authorization: Bearer ${userA.token} },
})
expect([403, 404]).toContain(res.status)
})
```

Where this fits in your test strategy

• Add authorization checks as a standing category in your API test suite, separate from functional and schema tests.
• Test with at least two distinct low-privilege accounts so cross-account access bugs surface automatically. Generating those accounts is easier with a dedicated approach to test-data-management.
• Track every API version and endpoint in an inventory, since untracked ones are what API9 describes.
• Fuzz numeric and UUID resource IDs in automated runs rather than relying on manual spot checks.
• Review rate limits and payload size caps as part of your non-functional test plan, not as an afterthought.

None of this replaces schema validation. It sits alongside it: one layer confirms the shape of data, the other confirms who is allowed to see it. Wire both into ci-cd-for-test-suites so authorization regressions block a release the same way a failing contract test does. Also watch for flakiness in these checks, since an intermittently skipped authorization test is worse than no test at all.