The TLDR

APIs are the backbone of modern applications — and the #1 target for attackers. The OWASP API Security Top 10 (2023) identifies the vulnerability classes that dominate API breaches: broken object-level authorization (BOLA), broken authentication, excessive data exposure, and lack of rate limiting. These aren’t exotic attacks. They’re the result of developers building APIs that trust the client, return more data than necessary, and don’t enforce authorization at every endpoint. If your API returns a user record when you change the ID in the URL, you have BOLA. If your API returns the full object when the client only needs three fields, you have excessive data exposure. These are the defaults, and the defaults are insecure.

The Reality

Gartner predicted that APIs would become the most frequent attack vector by 2022. They were right. Major API breaches include:

These weren’t zero-days or sophisticated exploits. They were broken authorization, missing authentication, and excessive data exposure — OWASP API Top 10 categories 1, 2, and 3.

How It Works

OWASP API Security Top 10 (2023)

API1: Broken Object Level Authorization (BOLA)

The most common API vulnerability. The API doesn’t verify that the authenticated user is authorized to access the specific object they’re requesting.

GET /api/users/123/orders    ← User 123's orders (legitimate)
GET /api/users/456/orders    ← User 456's orders (BOLA — should be denied)

The API checks that the request is authenticated (valid token) but not that user 123 is authorized to see user 456’s orders. The fix: check authorization at every object access, not just at the API gateway.

API2: Broken Authentication

Weak authentication mechanisms that allow attackers to compromise tokens, keys, or sessions:

API3: Broken Object Property Level Authorization

The API returns more data than the client needs, or allows modification of properties the client shouldn’t touch:

// API returns full user object including internal fields
{
  "id": 123,
  "name": "John",
  "email": "john@example.com",
  "role": "user",           // ← Shouldn't be in the response
  "internal_notes": "VIP",   // ← Definitely shouldn't be in the response
  "password_hash": "..."     // ← Critical data exposure
}

Mass assignment variant: the API accepts properties in PUT/PATCH that shouldn’t be modifiable:

// Attacker sends:
PATCH /api/users/123
{ "role": "admin" }
// If the API doesn't filter input properties, user becomes admin

API4: Unrestricted Resource Consumption

No rate limiting, no pagination limits, no request size limits. This enables:

API5: Broken Function Level Authorization

Horizontal privilege escalation: a regular user can access admin endpoints because authorization is only checked in the UI, not the API.

POST /api/admin/users/create    ← Admin endpoint
Authorization: Bearer <regular_user_token>
// If this succeeds, you have broken function-level authz

Common API Authentication Patterns

API Keys: Simple but problematic. Often long-lived, hard to rotate, and shared across environments. If leaked in a public repo (GitHub secret scanning catches thousands per day), they provide immediate access.

OAuth 2.0 / OIDC: The standard for delegated authorization. Complex to implement correctly. Common mistakes: not validating redirect URIs (enables authorization code interception), not using PKCE for public clients, and excessive scopes.

JWT (JSON Web Tokens): Stateless authentication that’s easy to get wrong:

mTLS (Mutual TLS): Certificate-based authentication where both client and server present certificates. Strong but complex to manage. Used primarily for service-to-service communication.

How It Gets Exploited

The IDOR/BOLA Pattern

The attacker authenticates with their own account, observes the API calls their client makes, and modifies the object IDs:

  1. Log in as user 123
  2. Observe: GET /api/users/123/documents returns user 123’s documents
  3. Change to: GET /api/users/124/documents
  4. If 124’s documents are returned, BOLA is confirmed
  5. Enumerate: loop through all user IDs, exfiltrating every user’s documents

This is how the Optus breach worked. This is how dozens of breaches work every year. It’s the most common API vulnerability because it requires only a browser’s developer tools to exploit.

GraphQL-Specific Attacks

GraphQL introduces unique API security concerns:

Introspection disclosure: By default, GraphQL exposes its entire schema through introspection queries. This gives attackers a complete map of every type, field, relationship, and mutation available.

Query complexity attacks: Deeply nested queries can consume exponential server resources:

query {
  users {
    friends {
      friends {
        friends {
          posts { comments { author { friends { ... } } } }
        }
      }
    }
  }
}

Batching attacks: GraphQL allows multiple queries in a single request, bypassing per-request rate limiting.

API Key Leakage

GitHub secret scanning detects over 100 types of API keys in public repositories. But keys also leak through:

What You Can Do

Authentication

  1. Use OAuth 2.0 / OIDC for user-facing APIs — with PKCE for public clients
  2. Short-lived tokens — access tokens should expire in minutes to hours, not days
  3. Rotate API keys regularly and on suspected compromise
  4. Never put secrets in client-side code — use a backend proxy
  5. Rate limit authentication endpoints — 5-10 attempts per minute maximum

Authorization

  1. Check authorization at every endpoint — not just at the API gateway or in the UI
  2. Use the user’s identity from the token to scope data access — never trust client-supplied user IDs for authorization
  3. Implement RBAC or ABAC with clear permission models
  4. Test authorization explicitly — your test suite should verify that user A cannot access user B’s resources

Data Exposure

  1. Return only the fields the client needs — use response DTOs, not raw database objects
  2. Never return internal IDs, hashes, or metadata in API responses
  3. Filter input properties on write operations — allowlist, don’t blocklist
  4. Disable GraphQL introspection in production

Rate Limiting and Monitoring

  1. Rate limit every endpoint — different limits for different operations (reads vs. writes vs. auth)
  2. Implement pagination with limits — don’t allow ?limit=999999
  3. Monitor for enumeration patterns — sequential ID access, rapid pagination, bulk export behavior
  4. Log API access with sufficient detail for forensic analysis
  5. Alert on anomalies — unusual volumes, unusual endpoints, unusual times

API Security Testing

  1. Include OWASP API Top 10 in your security testing checklist
  2. Fuzz API parameters — boundary values, type confusion, injection payloads
  3. Test authorization matrix — verify every role × endpoint combination
  4. Automated scanning — tools like Burp Suite, OWASP ZAP, and Postman security testing

Sources & Further Reading