← Back to blog

API Security Testing: The OWASP API Top 10 in Practice

NIMR Security Team
API securityOWASPAPI testing

API security testing is web testing without the page. There is no browser chrome to hide behind and no UI to limit what an attacker can reach: every object is addressable by ID and every function is one request away. The OWASP API Security Top 10 (2023 edition) is the reference we work from, and this post walks through how each risk shows up in a real test.

Why APIs need their own testing approach

APIs fail differently from web pages. Input validation bugs still exist, but the highest-impact findings are authorization flaws, and those require reasoning about the API's data model, not its markup. Scanners are weaker here because there is no page to crawl; parameter discovery and manual testing matter far more.

Object and function authorization

Three of the top five API risks are authorization problems, and they are the ones that turn into data breaches.

Broken object-level authorization (API1) is the classic: an endpoint takes an object ID from the URL or body and never checks the caller owns it. GET /users/{id}/orders with another user's ID returns their data (CWE-639). The fix is an authorization check on every object-ID endpoint, and the test is a systematic pass through all of them with two accounts.

Broken object property level authorization (API3) is mass assignment: a PATCH body that sets properties the client should not control. Sending "role":"admin" or "balance":0 and having it applied is CWE-915, improperly controlled modification of object attributes. The test is a review of what each update endpoint accepts versus what it should.

Broken function level authorization (API5) is a regular user's token reaching admin endpoints. It is the API version of a missing check, and it appears most often when admin functions are added to the same API without a separate authorization layer.

Our API penetration testing checklist covers the practical pass for all three.

Authentication and session handling

API2 covers weak authentication: credential stuffing against unrate-limited login endpoints, tokens that never expire, and JWT implementations with alg=none, weak signing keys, or missing exp. The test checks token lifecycle, revocation, and whether the lockout actually locks out.

Resource and business abuse

Unrestricted resource consumption (API4) is a cheap denial of service: an endpoint that does expensive work without rate limits, pagination caps, or payload limits. One loop over GET /search?limit=999999 can take a service down.

Unrestricted access to sensitive business flows (API6) is where scanners give up entirely. Coupon stacking, ticket resale, refund manipulation, and transaction replay are all correct HTTP with the wrong intent. They need a tester who understands the product, which is why business logic review is a standing part of our web and API engagements.

Server-side and configuration risks

Server-side request forgery (API7) shows up in endpoints that fetch a URL you provide: callbacks, image imports, and SSO assertions (CWE-918). The web app pentest walkthrough demonstrates one against a cloud metadata endpoint.

Security misconfiguration (API8) covers permissive CORS, verbose error messages, and debug endpoints left in production. Improper inventory management (API9) is the forgotten stuff: v1 endpoints, staging hosts, and undocumented endpoints that still respond. Inventory is a discovery problem more than a code problem. Unsafe consumption of APIs (API10) is the data you pull from third parties and webhooks, validated only after the damage.

GraphQL APIs add their own wrinkles: introspection queries map the whole schema for free, and deeply nested queries are a built-in resource-consumption test. If the target exposes GraphQL, the schema review and query-depth checks belong in scope.

How the test actually runs

A practical API assessment starts with inventory: every endpoint, version, and authentication requirement, pulled from OpenAPI specs, client source code, and captured traffic. From there it is a series of passes, one for authorization across every object-ID endpoint, one for authentication and token handling, one for injection and parsing edge cases, and one for the business flows unique to the product.

Two things are worth planning for. APIs usually need working credentials for multiple roles so authorization checks can be tested properly. And JSON and GraphQL need dedicated tooling rather than the browser-centric flows used for web testing.

What the report should look like

Every finding should carry a reproduction with the request and response pair, a CVSS 3.1 score, a CWE reference, business impact in your terms, and a remediation that names the layer where the fix belongs. Findings without a reproduction are not findings; they are suspicions.

Takeaways

  • Authorization is the top API risk: test every object-ID endpoint with multiple accounts.
  • Mass assignment and business flows need manual testing; no scanner finds them.
  • Check rate limits and resource consumption; cheap DoS is a real finding.
  • Hunt the inventory: v1 endpoints and staging hosts are still part of your attack surface.
  • Include webhooks and third-party API integrations in scope.

NIMR's web & API VAPT runs the OWASP API Top 10 with manual testing on top of automated scanning. Request an assessment to scope your API estate.