Security · Lesson 01

API Security Threats — the full landscape

Before you can defend an API you need a map of what can go wrong. This lesson builds that map: the three properties every attacker tries to destroy, the ten most-exploited API weakness classes, and the layered model that keeps attackers from a clean shot.

Start with what you are protecting

Security is not a feature you bolt on at the end — it is a property you either designed in or accidentally designed out. Before picking any control, ask: what are you protecting, and from whom?

The classical answer is the CIA triad — three properties that, if any one is violated, you have a security incident:

Think of your API as a delivery van carrying parcels. Confidentiality means the parcels stay sealed (no peeking). Integrity means the contents cannot be swapped during transit (the seals are tamper-evident). Availability means the van arrives on time (it is not blocked at a checkpoint or run off the road). An attacker only needs to break one of the three.

Threat modelling in four questions

A threat model is a structured way to answer: "what could go wrong?" before you build, not after you're breached. You don't need a formal notation; four questions get you 80% of the way:

1. What are you building? — list the API endpoints and the data they touch.
2. What can go wrong? — walk through each endpoint: what if the caller is not who they say, or sends a crafted input?
3. What will you do about it? — pick a countermeasure for each threat.
4. Did it work? — test your controls; repeat.

The OWASP API Security Top 10

OWASP (the Open Web Application Security Project) publishes a ranked list of the most-exploited API weaknesses, updated periodically. The 2023 edition is the current reference. Each category represents a real pattern seen across real breaches — these are not academic edge-cases.

Notice that seven of the ten are authorisation and access-control failures — not cryptography, not exotic exploits. The most exploited API bugs are "can this caller do this thing?" checks that are missing or wrong.

BOLA up close — the #1 bug

Broken Object-Level Authorization is so common it earned the top spot. The pattern is simple: a caller fetches a resource by ID, and the server checks only that the caller is authenticated — not that the caller owns the resource.

# Attacker is user 99. They try user 42's invoice:
GET /v1/invoices/42
Authorization: Bearer <valid_token_for_user_99>

# Vulnerable server response — no ownership check:
HTTP/1.1 200 OK
{
  "id": 42,
  "owner_id": 501,
  "amount": "$9,200",
  "card_last4": "4242"
}

# Fix — check ownership server-side every time:
# SELECT * FROM invoices WHERE id=42 AND owner_id=99
# → 0 rows → 404 Not Found (or 403 Forbidden)

Defense in depth — the layered model

No single control is unbreakable. Defense in depth means stacking independent layers so that an attacker who defeats one layer still faces the next. The classic analogy is a medieval castle: a moat, then a wall, then a gatehouse, then inner guards — each layer buys time and raises cost for the attacker.

For an API the layers look like this (outer to inner):

Under the hood: how it actually works

A BOLA attack runs in three phases: enumerate (guess or discover valid resource IDs), access (call the endpoint with a different user's ID using your own valid token), and exfiltrate (read the response and repeat). No special tooling is required — a loop in a shell script is enough.

# ── Phase 1: Attacker authenticates as their own account (user_99) ──────────
POST /v1/auth/token
{ "username": "attacker@example.com", "password": "hunter2" }

HTTP/1.1 200 OK
{ "token": "eyJ...", "user_id": 99 }

# ── Phase 2: Attacker views their own order to learn the URL pattern ─────────
GET /v1/orders/123
Authorization: Bearer eyJ...

HTTP/1.1 200 OK
{
  "id": 123,
  "owner_id": 99,
  "total": "$42.00"
}

# ── Phase 3: Attacker increments the ID — vulnerable server has no ownership check
GET /v1/orders/124
Authorization: Bearer eyJ...

# Vulnerable server — returns another user's order with PII:
HTTP/1.1 200 OK
{
  "id": 124,
  "owner_id": 501,
  "email": "victim@example.com",
  "address": "12 Maple St, Springfield",
  "card_last4": "7734"
}

# ── Phase 4: Attacker iterates 124 → 9999 in a loop to dump all orders ──────
# for id in $(seq 124 9999); do
#   curl -s -H "Authorization: Bearer eyJ..." /v1/orders/$id >> dump.json
# done

# ── Phase 5: Fixed server — ownership check blocks the request ───────────────
# Server SQL: SELECT * FROM orders WHERE id=124 AND owner_id=99 → 0 rows
HTTP/1.1 403 Forbidden
{ "error": "forbidden" }

How to debug & inspect it

Finding BOLA in your own API does not require a scanner. Access logs already contain the evidence — you just need to know what to look for.

Sources & further reading

• OWASP API Security Top 10 — 2023 edition
• OWASP — Threat Modeling
• OWASP — Authorization Cheat Sheet
• OWASP API1:2023 — Broken Object Level Authorization