APIs are the backbone of modern applications. Mobile apps, single-page applications, microservices architectures, and third-party integrations all depend on APIs to transfer data and execute operations. As APIs have become ubiquitous, they have also become the primary attack surface for modern web applications.
The OWASP API Security Top 10 (2023) defines the most critical API security risks. Unlike the general OWASP Top 10, which focuses on web application vulnerabilities in broad terms, the API Top 10 addresses the specific patterns and anti-patterns that create vulnerabilities in API-driven architectures.
This post covers each category in the 2023 edition, explains the testing strategies required to detect them, and describes how automated tools can provide comprehensive API security coverage.
Overview of OWASP API Security Top 10 (2023)
The 2023 edition reflects the evolving API landscape. Several categories have been renamed, restructured, or added since the 2019 version to address emerging attack patterns:
- API1:2023 Broken Object Level Authorization (BOLA)
- API2:2023 Broken Authentication
- API3:2023 Broken Object Property Level Authorization (BOPLA)
- API4:2023 Unrestricted Resource Consumption
- API5:2023 Broken Function Level Authorization (BFLA)
- API6:2023 Unrestricted Access to Sensitive Business Flows
- API7:2023 Server Side Request Forgery (SSRF)
- API8:2023 Security Misconfiguration
- API9:2023 Improper Inventory Management
- API10:2023 Unsafe Consumption of APIs
Each of these categories requires specific testing approaches. Let us examine the most critical categories in detail.
API1: Broken Object Level Authorization (BOLA)
BOLA is consistently the most common and most impactful API vulnerability. It occurs when an API endpoint uses user-supplied identifiers to access objects without verifying that the authenticated user has permission to access those objects.
The attack pattern is straightforward. An attacker identifies an API endpoint that accepts an object ID parameter, such as /api/users/12345/orders. They then modify the ID to access other users' data: /api/users/12346/orders. If the API does not verify that the authenticated user owns the requested resource, the attacker can enumerate and access arbitrary objects.
Authorization Matrix Testing
Effective BOLA testing requires an authorization matrix. This means testing each API endpoint with multiple authentication contexts to verify that authorization checks are properly enforced.
RedStrike tests across 5 authentication contexts: unauthenticated, regular user, premium user, admin, and service account. For each endpoint, the system verifies that:
- User A cannot access User B's resources
- A regular user cannot access admin endpoints
- A premium user cannot access resources belonging to a different premium user
- Service accounts are restricted to their intended scope
- Unauthenticated requests are properly rejected
Authorization Matrix:
Endpoint: GET /api/v1/users/{id}/profile
Context | Expected | Actual | Status
------------------|----------|--------|-------
Unauthenticated | 401 | 401 | PASS
User A | 200 (A) | 200(A) | PASS
User B | 403 | 200(A) | FAIL ← BOLA
Admin | 200 (any)| 200(any)| PASS
Service Account | 403 | 403 | PASSAPI2: Broken Authentication
Broken authentication encompasses weaknesses in how APIs verify user identity. This includes weak password policies, missing brute force protection, insecure credential storage, and improper session management.
For JWT-based authentication, this category includes several specific attack vectors that automated tools must test:
JWT Attack Chains
Algorithm none attack: Some JWT libraries allow the alg header to be set to none, bypassing signature verification entirely. The attacker modifies the JWT payload, sets the algorithm to none, and the API accepts the token as valid.
Key confusion attack: When an API supports both RSA and HMAC algorithms, an attacker can take the public key (which is often publicly available), use it as the HMAC signing key, and create a valid signature. The API verifies the signature using the wrong algorithm, accepting the forged token.
KID injection: The kid (Key ID) header parameter tells the API which key to use for verification. If the API does not sanitize the kid value, an attacker can inject path traversal characters to point to a different file, or use SQL injection to manipulate the key lookup.
# JWT alg:none attack example
Header: {"alg":"none","typ":"JWT"}
Payload: {"sub":"admin","role":"admin"}
Signature: (empty)
# If the API does not enforce algorithm whitelisting,
# this token is accepted as valid.API3: Broken Object Property Level Authorization (BOPLA)
BOPLA is a new category in the 2023 edition, replacing the older "Mass Assignment" category. It covers two related issues: excessive data exposure (returning more object properties than the client should see) and mass assignment (allowing clients to modify properties they should not have access to).
For example, a user profile API might return a user object that includes email, name, role, internal_notes, and salary fields. The API should only return email and name to other users, but if it returns all fields, it exposes sensitive internal data.
On the input side, a user profile update endpoint might accept a JSON body with all user properties. If the API does not filter which properties can be set by the user, an attacker can include "role": "admin" in the update request and escalate their privileges.
API4: Unrestricted Resource Consumption
This category covers denial of service through resource exhaustion. APIs that do not enforce rate limits, pagination, or input size restrictions are vulnerable to attacks that consume available resources and degrade service for legitimate users.
Automated testing for this category involves sending requests with oversized payloads, requesting unbounded result sets, and testing rate limiting enforcement across different endpoints and authentication contexts.
API5: Broken Function Level Authorization (BFLA)
BFLA occurs when an API does not properly enforce authorization at the function or endpoint level. While BOLA focuses on object-level access, BFLA focuses on whether a user can access functions intended for different roles.
A common example: a regular user can access the DELETE /api/admin/users/{id} endpoint because the API checks authentication but not authorization at the function level. The attacker does not need to access another user's data; they need to access an administrative function.
Testing BFLA requires mapping the API's functional endpoints, categorizing them by required role, and verifying that each endpoint properly enforces role-based access control.
GraphQL and gRPC Specific Testing
Modern APIs increasingly use non-REST protocols. GraphQL and gRPC each have unique security considerations that require specialized testing approaches.
GraphQL Testing
GraphQL APIs present unique challenges. The single endpoint model (/graphql) means traditional URL-based routing analysis does not apply. Attackers can craft complex queries that traverse relationships, extract excessive data, or cause denial of service through deeply nested queries.
Key GraphQL-specific tests include:
- Introspection queries: If introspection is enabled in production, attackers can discover the entire API schema, including internal fields and mutations.
- Query depth attacks: Deeply nested queries can cause exponential resource consumption on the server.
- Batch query abuse: Sending multiple operations in a single request to bypass rate limiting.
- Field suggestion exploitation: Using error messages to enumerate valid fields and types.
gRPC Testing
gRPC uses Protocol Buffers for serialization and HTTP/2 for transport. Testing gRPC APIs requires understanding the service definition, message structure, and streaming patterns. Key tests include:
- Unauthorized service method access: Verifying that each service method enforces proper authentication and authorization.
- Message manipulation: Testing whether the API properly validates protobuf message structure and field constraints.
- Streaming abuse: Forbid bidirectional streams that consume excessive server resources.
How Automated Tools Cover API Security
Automated API security testing requires several capabilities working together:
- API discovery: The tool must discover API endpoints through schema files (OpenAPI, gRPC proto), traffic analysis, or crawling. Without discovery, testing is limited to known endpoints.
- Authentication handling: API testing requires valid tokens for each authentication context. The tool must support JWT, OAuth 2.0, API keys, and custom authentication schemes.
- Authorization matrix testing: The tool must test each endpoint with multiple authentication contexts to detect BOLA and BFLA vulnerabilities.
- Protocol support: REST, GraphQL, gRPC, and WebSocket APIs each require different testing strategies. A comprehensive tool must handle all of them.
- Payload generation: The tool must generate context-appropriate payloads for each vulnerability category, not just generic injection strings.
RedStrike DAST provides all of these capabilities. The AI agent discovers endpoints, constructs authorization matrices, generates context-aware payloads, and tests each OWASP API Top 10 category systematically.
Building an API Security Program
Testing the OWASP API Top 10 is not a one-time activity. APIs evolve rapidly, new endpoints are deployed frequently, and authorization logic changes as features are added. Effective API security requires continuous testing integrated into the development lifecycle.
Start by mapping your API surface. Understand which endpoints exist, what authentication they require, and what authorization checks they enforce. Then deploy automated testing that covers the OWASP API Top 10 categories. Integrate that testing into your CI/CD pipeline so that every API change is validated before it reaches production.
The OWASP API Security Top 10 provides the framework. Automated testing provides the scale. Together, they provide the coverage that modern API-driven applications require.