api-security

API Security

Web-app and API security overlap but are not the same. APIs ship with different defaults (CORS-permissive, no CSRF tokens, often no rate-limiting), different consumers (mobile apps, integrations, scripts — not just browsers), and a different attack surface (object IDs in URLs, JSON bodies, scoped tokens). The OWASP API Security Top 10 (2023 edition) is the canonical reference; this skill walks each item with concrete detection and fix patterns.

When to invoke

• Designing a new REST or GraphQL API
• Reviewing an existing API before scaling user count
• After abuse — scraping, account takeover, suspicious 4xx/5xx patterns
• Adding a public-facing endpoint to a previously internal service
• An API is feeding a mobile or single-page app where the client cannot be trusted
• Periodic API audit (quarterly is reasonable)

API01:2023 — Broken Object Level Authorization (BOLA)

The #1 API vulnerability and not even close. Every endpoint that takes an ID and returns the corresponding resource must check the caller is allowed to see that specific object.

// Bad — any authenticated user reads any invoice
app.get('/api/invoices/:id', requireAuth, async (req, res) => {
  const invoice = await db.invoices.findUnique({ where: { id: req.params.id }});
  res.json(invoice);
});

// Good — scoped to the requester's ownership
app.get('/api/invoices/:id', requireAuth, async (req, res) => {
  const invoice = await db.invoices.findFirst({
    where: { id: req.params.id, userId: req.user.id }
  });
  if (!invoice) return res.status(404).json({ error: 'not found' });
  res.json(invoice);
});

Detection in a codebase:

# Every parameterized route is a BOLA candidate. Walk them.
grep -rEn ":id|:slug|:uuid" src/routes src/api app 2>/dev/null

# Routes that fetch by primary key alone — high-suspicion pattern
grep -rEn 'findUnique\\(\\{\\s*where:\\s*\\{\\s*id:' --include='*.{ts,js}' . | head

Patterns that make BOLA harder to introduce:

• Always include userId or tenantId in the where clause, not just the resource ID
• Use database row-level security (RLS) as a backstop — Postgres RLS plus per-request SET LOCAL app.current_user. See postgres-hardening.
• Use opaque IDs (UUIDs or hashids), not sequential integers. Doesn't fix BOLA but slows enumeration if it slips through.