OWASP API Security Top 10: Testing and Exploitation Guide

APIs are the backbone of modern applications — and they are consistently the most under-tested attack surface in bug bounty programs and penetration tests. The OWASP API Security Top 10 provides a structured framework for evaluating API security. This guide goes beyond the theory to show you exactly how to test and exploit each category.

Use the API Security Studio to craft and replay API requests while working through this methodology.

API1: Broken Object Level Authorization (BOLA / IDOR)

BOLA is the most common and impactful API vulnerability. The API accepts a user-supplied object ID and returns data without verifying the requesting user owns that object.

# Request your own order:
GET /api/v1/orders/10042

# Change to another user's order:
GET /api/v1/orders/10041
GET /api/v1/orders/10040

Test all numeric IDs, UUIDs, slugs, and hashes. Try incrementing, decrementing, and swapping IDs between two test accounts. Also look for indirect references — the API may accept an email address or username that resolves to another user's data.

API2: Broken Authentication

APIs often implement authentication incorrectly: weak JWT secrets, tokens that never expire, missing authentication on sensitive endpoints, or authentication that only checks the presence of a token rather than its validity.

# Test with no token:
GET /api/v1/admin/users

# Test with an expired token:
Authorization: Bearer [expired_jwt]

# Test with alg:none JWT:
Header: {"alg":"none","typ":"JWT"}
Payload: {"sub":"admin","role":"admin"}

See our Broken Authentication Testing guide for JWT-specific attacks and token prediction techniques.

API3: Broken Object Property Level Authorization (BOPLA / Mass Assignment)

The API exposes object properties that the user should not be able to modify. When creating or updating a resource, additional fields in the request body are accepted and applied.

# Normal request:
PATCH /api/v1/users/me
{"name": "Alice"}

# Attempt mass assignment:
PATCH /api/v1/users/me
{"name": "Alice", "role": "admin", "credits": 99999, "verified": true}

Full exploitation techniques are covered in our Mass Assignment Vulnerabilities guide.

API4: Unrestricted Resource Consumption

APIs without rate limiting allow attackers to exhaust server resources or perform brute force attacks. Test by sending rapid repeated requests to authentication endpoints, search endpoints, and any endpoint that triggers expensive operations (email sending, PDF generation, etc.).

# Brute force with ffuf:
ffuf -u https://api.target.com/v1/auth/login   -X POST   -H "Content-Type: application/json"   -d '{"email":"[email protected]","password":"FUZZ"}'   -w /usr/share/wordlists/passwords.txt   -fc 401

Also test GraphQL batching and aliases for bypassing per-request rate limits — covered in our GraphQL Security guide.

API5: Broken Function Level Authorization (BFLA)

BFLA differs from BOLA: instead of accessing another user's object, the attacker accesses admin-level functions as a regular user. REST APIs often expose HTTP methods that are not intended for regular users:

# Normal user can GET:
GET /api/v1/users/me  → 200 OK

# Try admin-level methods:
DELETE /api/v1/users/456  → should be 403, may be 200
PUT /api/v1/users/456/role  → check if role can be changed
GET /api/v1/admin/users  → enumerate admin endpoints

Use the Recon Hub to discover undocumented API endpoints via JavaScript file analysis and path enumeration.

API6: Unrestricted Access to Sensitive Business Flows

Some API flows are sensitive beyond just authentication — they have business impact when abused. Examples: unlimited coupon redemption, unlimited free trial signups, voting/rating endpoints without deduplication. Test these flows by automating them and observing if the application enforces any business logic restrictions beyond authentication.

API7: Server Side Request Forgery (SSRF)

APIs that accept URLs as input (webhooks, link previews, integrations, import-from-URL features) are prime SSRF targets. See our Advanced SSRF guide for full exploitation details, including cloud metadata access via IMDSv1.

# Test webhook URL parameter:
POST /api/v1/integrations/webhook
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

API8: Security Misconfiguration

Common API misconfigurations include: CORS set to wildcard (Access-Control-Allow-Origin: *), HTTP methods not restricted, debug endpoints left enabled in production, verbose error messages exposing stack traces or database queries, and TLS not enforced.

# Check CORS:
curl -H "Origin: https://evil.com" https://api.target.com/v1/users/me -I

# Look for: Access-Control-Allow-Origin: https://evil.com
# Combined with: Access-Control-Allow-Credentials: true
# This allows cross-origin authenticated requests → account takeover

API9: Improper Inventory Management

Old API versions left running alongside new ones often lack the security controls of the current version. Always test:

• /api/v1/ when the app uses /api/v3/
• /api/beta/, /api/internal/, /api/mobile/
• Different API hostnames: api-old.target.com, api-dev.target.com

Mobile apps are often a goldmine here — decompile the APK or IPA and extract any hardcoded API endpoints and credentials.

API10: Unsafe Consumption of APIs

When the target API itself consumes third-party APIs, vulnerabilities in the upstream service can be exploited. If the target trusts and reflects data from a third-party API, inject XSS payloads or SQL injection strings into data that flows through the third-party service into the target.

Building a Complete API Test Methodology

1. Collect all API endpoints via JS analysis, mobile app decompilation, and the Recon Hub.
2. Map authentication requirements for each endpoint.
3. Test BOLA on every ID parameter with two test accounts.
4. Attempt all HTTP methods on every endpoint.
5. Fuzz JSON body keys for mass assignment opportunities.
6. Check rate limiting on authentication and sensitive business endpoints.
7. Use the API Security Studio to replay and modify requests systematically.