Skip to content
Pwnversity

API Security (OWASP API Top 10)

APIs (REST, JSON, mobile, microservices) are today the largest attack surface: they expose business logic directly, without the UI layer that sometimes hides endpoints. The attacker doesn’t see a website, they see data and verbs, and the dominant bugs aren’t classic injections but authorization failures: objects and functions reachable by whoever shouldn’t. OWASP maintains an API-specific Top 10 precisely because the threat model differs from traditional web.

Threat model

Section titled “Threat model”

In an API, the client (mobile app, SPA, another service) knows the endpoints and sends identifiers directly. If the server authorizes “because authenticated” but doesn’t check that this user may touch this object or this function, it falls. The front protects nothing: every endpoint is reachable with curl.

OWASP API Security Top 10 (2023) — the essentials

Section titled “OWASP API Security Top 10 (2023) — the essentials”
  • API1 BOLA (Broken Object Level Authorization): the object id is manipulable and ownership isn’t validated → the APIs’ IDOR, the #1 bug.
  • API2 Broken Authentication: weak tokens, badly-validated JWTs, login endpoints with no rate-limit.
  • API3 Broken Object Property Level Authorization: merges excessive data exposure (the API returns more fields than the UI shows) and mass assignment (it accepts fields it shouldn’t write).
  • API4 Unrestricted Resource Consumption: no rate-limit or size limits → DoS and cost (also SMS/email abuse).
  • API5 BFLA (Broken Function Level Authorization): reaching another role’s functions (admin endpoints) by not checking the role.
  • API6 Unrestricted Access to Sensitive Business Flows: sensitive flows automatable without friction (bulk purchase, reservations).
  • API7 SSRF: the API makes requests to user-supplied URLs.
  • API8 Security Misconfiguration: lax CORS, extra verbs, missing headers, open debug.
  • API9 Improper Inventory Management: old versions (/v1/) and shadow/deprecated endpoints left unpatched.
  • API10 Unsafe Consumption of APIs: blindly trusting third-party APIs you integrate.

Red Team

Section titled “Red Team”

Discovery

Section titled “Discovery”
  • Capture the mobile app/SPA traffic (Burp + proxy) to enumerate real endpoints.
  • Look for docs: /swagger.json, /openapi.json, /api-docs, /graphql, /v1/, /v2/ routes.
  • Enumerate old versions and undocumented endpoints (fuzz with API wordlists).

By hand: key tests

Section titled “By hand: key tests”
# BOLA/API1 : change the id to another user's (with TWO accounts)
GET /api/v1/users/1337/orders        # does it return someone else's orders?


# Excessive data exposure / API3: look at ALL JSON fields
GET /api/v1/users/me                 # passwordHash, isAdmin, tokens?


# Mass assignment / API3: add privileged fields
PATCH /api/v1/users/me  {"role":"admin","verified":true}


# BFLA/API5 : try admin verbs and routes with a normal token
DELETE /api/v1/users/1
POST   /api/v1/admin/promote {"user":2}


# API9 : old unpatched versions
GET /api/v1/...   vs   /api/v2/...

BOLA/BFLA methodology: two accounts. Do the action with account A, capture the request, replay it with B’s token targeting A’s objects/functions. Automate with the Autorize extension.

Tools

Section titled “Tools”
  • Burp Suite + Autorize (automatic authorization-flaw detection with two sessions).
  • Postman / Insomnia to build requests.
  • kiterunner, ffuf with API-route wordlists; Arjun for parameter discovery.
  • nuclei API-misconfig templates.

Impact

Section titled “Impact”

Read/write of any user’s data (BOLA), escalation to admin (BFLA), PII leakage via over-exposure, account takeover, DoS from missing limits.

Blue Team

Section titled “Blue Team”

Detection

Section titled “Detection”
  • One token accessing many different object IDs (BOLA/scraping pattern).
  • Calls to admin endpoints with user-role tokens (BFLA).
  • Volume spikes without rate-limit; access to deprecated /v1/ versions.

Telemetry

Section titled “Telemetry”

Log user, object/ID, and function per request; correlate identity ↔ accessed resources.

Hardening

Section titled “Hardening”
  • Object- and function-level authorization on every endpoint: verify the authenticated user owns/has the role for that resource, always server-side.
  • Return only the needed fields (explicit DTOs/serializers); allowlist of writable fields (against mass assignment).
  • Rate-limiting and size/pagination limits on every endpoint; protect sensitive flows.
  • API inventory: retire old versions, document and patch; close shadow endpoints.
  • Secure config: strict CORS, minimal verbs, no debug in production; validate input against a schema.
  • Robust authentication (well-validated JWT, expiring tokens, rate-limit on login).

Response

Section titled “Response”

Revoke tokens, audit which objects/functions were accessed improperly, fix the missing authorization, and retire vulnerable versions.

CVEs and real-world cases

Section titled “CVEs and real-world cases”
  • Peloton (2021) — BOLA exposing any user’s profile data via the API.
  • USPS Informed Visibility (2018) — an API without authorization exposed 60M users’ data.
  • T-Mobile / Experian / many — breaches from API endpoints with inadequate access control.
  • Optus (2022) — an unauthenticated API leaked millions of records; a reference BOLA/misconfig case.

Testing checklist

Section titled “Testing checklist”
  • Are object IDs manipulable without an ownership check? (BOLA)
  • Does the JSON return extra sensitive fields? (excessive data exposure)
  • Can privileged fields be written? (mass assignment)
  • Admin functions/verbs reachable with a normal token? (BFLA)
  • Are there rate-limit and size/pagination limits? (resource consumption)
  • Are there old versions (/v1/) or shadow endpoints unpatched?
  • Is authentication (JWT/token) validated correctly?
  • Is the config (CORS, verbs, debug, headers) secure?

References

Section titled “References”