API Security Threats — the full landscape

A user updates their profile via PUT /users/42. While exploring the API, the attacker issues a normal GET /users/42 and spots a "role": "user" field in the response. They craft a write request that adds that field back with an elevated value. The server uses an ORM method like Rails's .update(params) or a generic Object.assign(user, req.body) in Node — it blindly maps every field in the request body to the model. The attacker's role: admin is silently persisted, granting full administrative access without any privilege check ever firing.

# Attacker discovers role field via a normal GET response, then writes it back elevated
PUT /users/42
Authorization: Bearer <valid_user_token>
Content-Type: application/json

{ "name": "Alice", "role": "admin", "verified": true }

# Vulnerable server — ORM blindly maps all fields:
HTTP/1.1 200 OK
{ "id": 42, "name": "Alice", "role": "admin", "verified": true }

# Fix — use an explicit allowlist; never mass-assign untrusted fields:
# allowed = ['name', 'email', 'avatar_url']
# user.update(pick(req.body, allowed))   ← role and verified are silently dropped

Admin-only routes are often on a predictable path pattern (/admin/, /internal/, /manage/). Developers sometimes omit the authorization middleware because they assume "only admins know the URL." An attacker who is authenticated as a regular user simply guesses the path using common wordlists or by noticing admin-flavored links in JavaScript bundles. The route exists, the handler runs, and because no RBAC check was ever added, the full admin response is returned. Security by obscurity — hiding the URL — is not access control.

# Attacker is authenticated as a regular user, guesses the admin route
GET /api/v1/admin/users
Authorization: Bearer <regular_user_token>

# Vulnerable server — route exists but authorization middleware was never added:
HTTP/1.1 200 OK
[
  { "id": 1, "email": "alice@example.com", "role": "admin" },
  { "id": 2, "email": "bob@example.com", "role": "user" }
  // ... full user list returned to a regular user
]

# Secure server — RBAC checked on every route, never by URL convention alone:
HTTP/1.1 403 Forbidden
{ "error": "insufficient_scope" }

# Defense: enforce require_role('admin') middleware on every admin route explicitly.
# Never rely on URL obscurity — attackers enumerate paths with wordlists (ffuf, dirsearch).

A legitimate POST /checkout/apply-coupon endpoint is designed for users to apply a promotional code at checkout. Because it is a public, functional feature, no bot protection is applied. An attacker scripts a loop that tries short, human-memorable codes (or a small published pattern space) at 10,000 requests per minute — a brute-force coupon stuffing attack. Valid codes return a discount; invalid ones return a 400. Weak codes get found quickly; the endpoint behaves exactly as designed — the problem is it was never protected against automated, high-volume use.

# Bot iterates possible coupon codes at scale — no rate limit stops it
POST /checkout/apply-coupon
{ "code": "SAVE50" }   # → 200 OK {"discount": "50%"}  ← valid code found

POST /checkout/apply-coupon
{ "code": "SAVE51" }   # → 400 Bad Request {"error": "invalid code"}

# Math: full 6-char base36 space = 36^6 ≈ 2.18e9 codes.
# At 10,000 req/min → ≈ 2.18e9 / 1e4 ≈ 2.18e5 min ≈ 151 days for full brute force.
# Real risk is shorter: weak patterns (SAVE##, SUMMER) collapse the space to minutes.
# Defense: rate limit per user session (e.g. 5 attempts/min), add CAPTCHA on
# repeated failures, use cryptographically random unguessable codes (≥128 bits),
# and alert on anomalous coupon-check volume from a single token or IP.

An API offers a "render preview" feature: the client supplies a URL and the server fetches it to generate a thumbnail or extract metadata. The URL is caller-controlled. An attacker supplies the AWS instance metadata endpoint (http://169.254.169.254/) — a non-routable IP that is reachable from the server's internal network but not from the public internet. The server dutifully fetches it and returns the response, which contains IAM credentials, instance identity documents, and internal network topology. No authentication is required to reach the metadata service — only being on the same internal network, which the server is. The attacker now has temporary AWS credentials and can move laterally through the cloud environment.

# Attacker supplies the AWS instance metadata URL as the preview target
POST /api/render-preview
Authorization: Bearer <valid_user_token>
Content-Type: application/json

{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }

# Vulnerable server fetches the internal URL and returns the body:
HTTP/1.1 200 OK
{
  "preview": "MyEC2InstanceRole"   // ← IAM role name leaked
}

# Follow-up — attacker fetches the credentials directly:
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/MyEC2InstanceRole" }
# Response contains AccessKeyId, SecretAccessKey, Token — full AWS access

# Defense: validate/allowlist URLs before fetching (only allow specific trusted domains),
# block all RFC-1918 and link-local ranges (10.x, 172.16-31.x, 192.168.x, 169.254.x)
# at the HTTP client level. Never pass raw user-supplied URLs to internal HTTP clients.

A team migrates from v1 to v2 of their API, correctly adding authentication and rate limiting to all v2 routes. The v1 routes are left in place for backward compatibility during a transition period — but the security hardening was never retrofitted to them. An attacker enumerates common path prefixes (/api/v1/, /api/v2/, /internal/, /dev/, /staging/) using automated tools. The v1 endpoint responds and returns data without the auth checks present in v2. The attacker exploits the forgotten endpoint to access user records without a valid token — a vulnerability that does not exist anywhere in the v2 codebase and was never included in any security review.

# v1 endpoint — forgotten during migration, auth checks were never added
GET /api/v1/users/42
# No Authorization header required

HTTP/1.1 200 OK
{ "id": 42, "email": "alice@example.com", "phone": "+1-555-0100" }

# v2 endpoint — correctly secured, returns 401 without a token
GET /api/v2/users/42
HTTP/1.1 401 Unauthorized

# Attacker enumeration pattern — automated path guessing:
# ffuf -u https://api.example.com/api/FUZZ/users/1 -w versions.txt
# versions.txt: v1, v2, v3, internal, dev, staging, beta, legacy

# Defense: maintain an API gateway inventory of every route (including old versions).
# Decommission old routes explicitly — return 410 Gone, not 200.
# Apply the same auth/authz middleware to ALL versions of the same route.

Treating authentication as sufficient for authorization. A caller with a valid token is authenticated — you know who they are. That says nothing about what they're allowed to do. Most OWASP Top 10 entries are authorization failures, not authentication failures. Always ask both: "Is this caller who they say?" and "Are they allowed to do this to this resource?"

1. List every GET/PUT/PATCH/DELETE endpoint that accepts a resource ID (e.g. /orders/{id}, /users/{id}/profile). These are all candidates for BOLA.
2. For each endpoint, find the database query it executes and check whether it filters on owner_id = current_user (or equivalent). A query like SELECT * FROM orders WHERE id = ? with no ownership predicate is vulnerable.
3. Write a test with two user accounts: authenticate as user A, then call a resource that belongs to user B. The response must be 403 or 404 — if it is 200, you have BOLA.
4. Check indirect object references too — not just top-level IDs. If your API exposes nested resources (/orders/{order_id}/items/{item_id}), verify that the item actually belongs to that order and that the order belongs to the caller.
5. Review your logs for the patterns above: sequential-ID runs from a single token, cross-user owner_id in 200 responses, and anomalous per-token resource access counts.