API Security Testing: The OWASP API Top 10 in Practice

APIs have become the primary attack surface of modern applications. Where traditional web application testing focused on browser-rendered HTML, today's security assessments must contend with REST, GraphQL, gRPC, and WebSocket interfaces — often with less visible documentation and weaker authentication controls than the application's primary UI. The OWASP API Security Top 10 (2023 edition) provides the most widely used reference taxonomy for API vulnerabilities. This article walks through each category with practical examples from real-world testing.

API1: Broken Object Level Authorisation (BOLA)

BOLA — sometimes called Insecure Direct Object Reference (IDOR) in the web application context — is consistently the most prevalent and highest-impact API vulnerability. It occurs when an API accepts user-supplied identifiers (IDs, UUIDs, filenames) and uses them to access resources without verifying that the requesting user is authorised to access that specific resource. A classic example: a banking API that returns account details at `/api/v1/accounts/{accountId}` without checking whether the authenticated user owns that account.

In testing, BOLA is often straightforward to identify but requires careful, systematic verification. Enumerate all ID-parameterised endpoints, create two test accounts, and attempt to access Account A's resources using Account B's credentials. Horizontal privilege escalation (one user accessing another user's data) and vertical privilege escalation (a standard user accessing admin-level resources) are both BOLA variants. CVSS scores for confirmed BOLA findings in BFSI and healthcare APIs routinely reach 8.0–9.0 (High/Critical).

API2: Broken Authentication

Authentication vulnerabilities in APIs include weak token validation, missing authentication on endpoints that should be protected, predictable session identifiers, and insufficient brute-force protections. JWT (JSON Web Token) misconfigurations are a particularly common finding: the `none` algorithm attack (accepting unsigned tokens), algorithm confusion attacks, insufficient token expiry, and secrets that fail entropy thresholds. Test every authentication flow: initial login, token refresh, password reset, and account recovery.

API3: Broken Object Property Level Authorisation

API3 addresses a subtler variant of authorisation failure: an authenticated user being able to read or write object properties they should not have access to. This is often exploited through mass assignment — submitting additional fields in a PATCH or PUT request that the API accepts but should not allow a standard user to modify (for example, setting `isAdmin: true` on a user object). GraphQL APIs are particularly susceptible to object property exposure through introspection and overly permissive resolvers.

API4–API7: Unrestricted Resource Consumption, Function-Level Auth, and Injection

API4 (Unrestricted Resource Consumption) covers rate limiting failures: endpoints that can be flooded to cause service degradation or that accept unbounded query parameters consuming excessive compute. API5 (Broken Function Level Authorisation) is the admin function variant of BOLA — standard users accessing administrative API endpoints. API6 (Unrestricted Access to Sensitive Business Flows) covers business logic abuse: credential stuffing on login endpoints, bulk account enumeration, gift card balance exhaustion.

API7 (Server Side Request Forgery — SSRF) has become increasingly critical as cloud-hosted APIs can be weaponised to reach cloud metadata endpoints. A successful SSRF against an AWS-hosted API that reaches the EC2 metadata service at 169.254.169.254 can expose IAM credentials, enabling significant lateral movement. Always test URL parameters, webhook handlers, and any API functionality that makes outbound HTTP requests.

API8–API10: Security Misconfiguration, Improper Inventory, and Unsafe Consumption

API8 (Security Misconfiguration) covers a wide range of issues: CORS policies that trust all origins, verbose error messages exposing stack traces, HTTP methods enabled that should not be (e.g., TRACE, DELETE on public endpoints), and missing security headers. API9 (Improper Inventory Management) — shadow APIs, undocumented endpoints, and deprecated API versions still accessible — is one of the most frequently underestimated risks. In practice, large organisations regularly discover production-accessible API endpoints that have not been documented or tested in years.

API10 (Unsafe Consumption of APIs) covers your application's trust of third-party APIs: insufficient validation of data received from upstream providers, insecure integration patterns, and over-privileged third-party API tokens. As supply chain attacks targeting API integrations increase, this is a growing concern, particularly in fintech and open banking environments.

Building a repeatable API testing methodology

Effective API security testing begins with comprehensive discovery: enumerate all API endpoints from OpenAPI/Swagger documentation, JavaScript bundle analysis, traffic capture, and active probing. Build a request collection covering every endpoint and every parameter type. Test authentication and authorisation systematically — do not rely on the UI flow. Use fuzzing to discover undocumented parameters and injection points. OWASP ASVS Level 2 provides the detailed control checklist that should guide API security verification for most applications.

CyVigilant's VAPT service includes dedicated API security testing using the OWASP API Top 10 and ASVS methodology. To discuss your API security assessment requirements, talk to an expert.