What API Security Actually Means

// What the frontend sends — constrained by the UI
await fetch('/api/projects/42', {
  method: 'PATCH',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'Renamed project' }),   // one editable field
});

// What an attacker sends — constrained by nothing
// PATCH /api/projects/42
// {
//   "name": "Renamed project",
//   "ownerId": 1,             ← reassign it to themselves
//   "tier": "enterprise",     ← upgrade the plan
//   "isPublic": true,         ← expose it
//   "deletedAt": null,        ← undelete something
//   "__proto__": { "isAdmin": true }   ← prototype pollution, for good measure
// }

// ❌ The handler that trusts the shape the UI happens to send
app.patch('/api/projects/:id', auth, async (req, res) => {
  const project = await db.projects.update(req.params.id, req.body);
  res.json(project);
});

// ✅ Explicit allowlist, and ownership inside the query
const UPDATABLE = ['name', 'description'];

app.patch('/api/projects/:id', auth, async (req, res) => {
  const patch = Object.fromEntries(
    Object.entries(req.body ?? {}).filter(([k]) => UPDATABLE.includes(k))
  );
  if (!Object.keys(patch).length) {
    return res.status(400).json({ error: 'no_updatable_fields' });
  }

  const updated = await db.projects.updateWhere(
    { id: req.params.id, ownerId: req.user.id },   // authorization IS the query
    patch,
  );
  if (!updated) return res.status(404).json({ error: 'not_found' });

  res.json(publicProject(updated));                 // and a shaped response
});

# Your OpenAPI spec is a complete map of the attack surface. That is fine —
# obscurity is not a control — but know what it tells someone.

curl -s https://dfg.com/openapi.json | jq -r '
  .paths | to_entries[] |
  .key as $path | .value | to_entries[] |
  "\(.key | ascii_upcase) \($path)"' | head -20

# GET    /api/users/{id}
# PATCH  /api/users/{id}
# DELETE /api/users/{id}          ← is this admin-only? enforced where?
# GET    /api/invoices/{id}       ← sequential ids? scoped to the caller?
# POST   /api/admin/impersonate   ← who can reach this?
# GET    /api/internal/metrics    ← why is 'internal' on a public spec?

# The questions an attacker asks, in order:
#   1. which endpoints take an object id?           → BOLA candidates
#   2. which are admin/internal by name?            → BFLA candidates
#   3. which accept a body?                         → mass assignment, injection
#   4. which return collections?                    → excessive exposure, DoS
#   5. which touch another system?                  → SSRF

# Run this against your own spec and answer all five. That is a threat model.

For each endpoint, answer these. An unanswered one is a finding.

1. AUTHENTICATION
   Who can reach it unauthenticated?
   Is the identity taken from a verified credential and nothing else?

2. AUTHORIZATION — OBJECT
   It takes an id. Where is the ownership/tenant check?
   Is it INSIDE the query, or a check after the fetch?
   Does a foreign object return 404 rather than 403?

3. AUTHORIZATION — FUNCTION
   Is this action restricted by role or scope?
   Is that enforced on the ROUTE, or assumed because the UI hides the button?

4. INPUT
   Is the body validated against a schema, with unknown fields REJECTED?
   Which fields are writable? Is that an allowlist or a denylist?

5. OUTPUT
   Is the response shaped explicitly, or is a model serialised?
   What is in it that the screen never shows?

6. RESOURCE USE
   Is there a cap on limit / depth / size / duration?
   What does this cost if called 10,000 times a minute?

7. OUTBOUND
   Does it fetch a URL, render a template, or run a query from user input?

# Seven questions, five minutes, and it catches the majority of real findings.