API Security: OWASP API Top 10

The OWASP API Security Top 10 #

The Open Web Application Security Project (OWASP) maintains a list of the most critical API security risks. The 2023 edition reflects the current threat landscape for APIs. As a QA engineer, understanding these vulnerabilities helps you design test cases that catch security flaws before they reach production.

APIs are the primary attack surface for modern applications. Unlike web applications where a browser enforces some security, API clients can send any request — making APIs especially vulnerable when server-side validation is weak.

API1:2023 — Broken Object Level Authorization (BOLA) #

BOLA is the most common API vulnerability. It occurs when the API does not check whether the authenticated user has permission to access a specific resource.

How it works:

# User A is authenticated and views their own order
GET /api/orders/1001
Authorization: Bearer <user-A-token>
→ 200 OK (Order belongs to User A)

# User A changes the ID to access User B's order
GET /api/orders/1002
Authorization: Bearer <user-A-token>
→ 200 OK (Order belongs to User B — BOLA vulnerability!)

Testing approach:

1. Authenticate as User A and note the IDs of their resources.
2. Authenticate as User B.
3. Using User B’s token, try to access User A’s resources by ID.
4. If the API returns the data, BOLA exists.

Test this on every endpoint that accepts an object ID: orders, profiles, documents, messages, payments.

API2:2023 — Broken Authentication #

Authentication mechanisms in APIs often have flaws: weak token generation, missing token expiration, tokens in URLs, or no rate limiting on login attempts.

Common test cases:

• Send requests without the Authorization header — does the API return data or a proper 401?
• Use an expired JWT — does the API reject it?
• Modify the JWT payload without re-signing — does the API validate the signature?
• Brute-force the login endpoint — is there rate limiting?
• Check if tokens are in URL query parameters (they appear in server logs).

# Test missing auth
curl -X GET https://api.example.com/users/me
# Expected: 401 Unauthorized

# Test expired token
curl -X GET https://api.example.com/users/me \
  -H "Authorization: Bearer <expired-token>"
# Expected: 401 Unauthorized

API3:2023 — Broken Object Property Level Authorization #

This combines two older risks: excessive data exposure and mass assignment. The API either returns more data than the client needs or accepts more data than it should.

Excessive data exposure example:

GET /api/users/123
{
  "id": 123,
  "name": "John",
  "email": "john@example.com",
  "ssn": "123-45-6789",       // Should never be returned
  "salary": 85000,             // Internal field exposed
  "role": "admin",             // Privilege info leaked
  "password_hash": "abc123..."  // Critical exposure
}

Mass assignment example:

# Normal user update
PUT /api/users/123
{ "name": "John Updated" }

# Attacker adds extra fields
PUT /api/users/123
{ "name": "John Updated", "role": "admin", "is_verified": true }

Testing approach: For every endpoint, compare the response fields against what the client actually needs. For write endpoints, send extra fields and check if the API processes them.

API4:2023 — Unrestricted Resource Consumption #

APIs that do not limit resource consumption are vulnerable to denial of service. This includes missing rate limiting, no pagination limits, and allowing uploads without size restrictions.

Test cases:

• Request a list endpoint without pagination — does it return millions of records?
• Send a file upload with an extremely large file — is there a size limit?
• Make rapid sequential requests — does rate limiting kick in?
• Send a GraphQL query with deep nesting — does the server limit query complexity?

API5:2023 — Broken Function Level Authorization #

Users can access administrative functions by guessing the endpoint URL pattern.

# Regular user endpoint
GET /api/users/123

# Admin endpoints that regular users should not access
DELETE /api/users/123
GET /api/admin/users
POST /api/admin/config

Testing approach: Map all endpoints including admin ones (from documentation or by fuzzing). Try accessing admin endpoints with regular user tokens.

API6:2023 — Unrestricted Access to Sensitive Business Flows #

Automated abuse of legitimate business flows: ticket scalping, mass account creation, coupon abuse. The API provides no mechanism to distinguish legitimate users from bots.

API7:2023 — Server Side Request Forgery (SSRF) #

The API fetches a URL provided by the user without validation, allowing attackers to scan internal networks.

# Normal request
POST /api/fetch-preview
{ "url": "https://example.com/article" }

# SSRF attack
POST /api/fetch-preview
{ "url": "http://169.254.169.254/latest/meta-data/" }
# Accesses AWS metadata service from inside the network

API8:2023 — Security Misconfiguration #

Missing security headers, verbose error messages, unnecessary HTTP methods enabled, CORS misconfiguration.

Quick checks:

• Are X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security headers present?
• Does the API return stack traces in error responses?
• Is CORS configured to allow * origins?
• Are OPTIONS, TRACE, and other unnecessary methods enabled?

API9:2023 — Improper Inventory Management #

Old, unpatched API versions remain accessible. Shadow APIs and beta endpoints are not documented or monitored.

Test: Check if /api/v1/ still works when /api/v2/ is the current version. Look for /api/internal/, /api/debug/, /api/beta/ endpoints.

API10:2023 — Unsafe Consumption of APIs #

The API trusts data from third-party APIs without validation. If a third-party service is compromised, the vulnerability propagates.

Exercise: API Security Testing Walkthrough #

Perform a security assessment of a sample API using the OWASP API Top 10 as your framework.

Setup #

Use OWASP’s intentionally vulnerable APIs for safe practice:

• crAPI (Completely Ridiculous API): https://github.com/OWASP/crAPI
• VAmPI (Vulnerable API): https://github.com/erev0s/VAmPI

Install crAPI locally:

docker compose -f docker-compose.yml up -d

Part 1: BOLA Testing #

1. Create two user accounts (User A and User B).
2. As User A, create a resource (e.g., a vehicle or order).
3. Note the resource ID.
4. Authenticate as User B and try accessing User A’s resource:

# Get User A's vehicle (while authenticated as User B)
curl -X GET http://localhost:8888/api/v2/vehicle/<user-a-vehicle-id> \
  -H "Authorization: Bearer <user-b-token>"

5. Document whether the API returns User A’s data or denies access.

Part 2: Authentication Testing #

Test the authentication flow:

# 1. Try accessing protected endpoint without token
curl -X GET http://localhost:8888/api/v2/user/dashboard

# 2. Try with malformed token
curl -X GET http://localhost:8888/api/v2/user/dashboard \
  -H "Authorization: Bearer invalid-token"

# 3. Try brute force on login (10 rapid attempts)
for i in {1..10}; do
  curl -s -X POST http://localhost:8888/api/auth/login \
    -H "Content-Type: application/json" \
    -d '{"email":"test@test.com","password":"wrong'$i'"}'
done

Part 3: Data Exposure Testing #

For each API endpoint:

1. Make a legitimate request and examine every field in the response.
2. List fields that should not be exposed to the client.
3. For write endpoints, send extra fields and check if they are accepted.

Part 4: Build a Security Test Checklist #

Create a reusable checklist based on your findings:

Deliverables #

After completing the exercise:

1. A security test report listing each vulnerability found, its OWASP category, severity (Critical/High/Medium/Low), and reproduction steps.
2. A reusable security testing checklist customized for your API.
3. Recommendations for fixing each vulnerability found.

Integrating Security Testing into CI/CD #

Automate security checks in your pipeline:

• OWASP ZAP — Run automated scans against your API in CI.
• Nuclei — Template-based scanner for known API vulnerabilities.
• Custom scripts — Encode your BOLA and auth tests as automated test cases that run on every deployment.

Security testing is not a one-time activity. Every new endpoint, parameter, or authentication change needs security review.