OWASP API Security Top 10 (2023): The Risks Your Web Scanner Misses

Why APIs need their own Top 10

The classic OWASP Top 10 is about how a browser-rendered web app breaks: injection, XSS, broken access control through the UI. But an API has no UI. The attacker talks straight to your JSON endpoints, sees every parameter, and replays requests at will. The failures shift from 'what can I inject into a page' to 'what object can I reach that is not mine'.

That is why OWASP publishes a separate API Security Top 10. The 2023 edition is dominated not by injection but by authorization, three of the top five entries are some flavor of 'you forgot to check who is asking'. A scanner that crawls HTML will sail right past all of them.

The one idea behind half the list: authorization

API security is mostly the discipline of checking, on every single request, that the authenticated caller is allowed to touch this exact object and this exact operation.

Anatomy of the #1 risk: BOLA

BOLA (Broken Object-Level Authorization) is the most common and most damaging API flaw. The pattern: an endpoint takes an object id from the URL, fetches that object, and returns it, without ever checking that the object belongs to the caller. Change the id, get someone else's data.

1. 1

   Log in legitimately

   The attacker creates a normal account and gets a valid token for tenant A. Authentication is fine, that is the trap.

2. 2

   Find an object id

   They request their own invoice, /invoices/1042, and see a sequential integer id in the URL and body.

3. 3

   Tamper with the id

   They change 1042 to 1043, 1044, 9999, IDOR-style enumeration straight against the API.

4. 4

   Harvest

   Every request that returns 200 instead of 403 is another tenant's data. A script walks the whole id space in minutes.

All ten risks, mapped

Here is the full 2023 list. Read the 'fix' column as a checklist, most are a single guard you either have or you do not.

The vulnerable endpoint

Theory is cheap. Here is a real BOLA bug, an Express handler that authenticates the user but never checks who owns the invoice. It looks fine in code review until you ask the one question: 'whose invoice is this?'

// requireAuth has already verified the JWT and set req.user.
// Looks safe, but it never checks ownership.
router.get('/invoices/:id', requireAuth, async (req, res) => {
  const invoice = await db.invoice.findUnique({
    where: { id: Number(req.params.id) },
  });

  if (!invoice) return res.status(404).json({ error: 'Not found' });

  // BOLA: any logged-in user can read ANY invoice by id.
  return res.json(invoice);
});

The fixed endpoint

The fix is one clause: scope the query to the caller, or compare the owner after fetching. Scoping in the query is best, it is impossible to forget the check because there is no row to leak.

router.get('/invoices/:id', requireAuth, async (req, res) => {
  // Ownership is part of the lookup, not an afterthought.
  const invoice = await db.invoice.findFirst({
    where: {
      id: Number(req.params.id),
      ownerId: req.user.id, // <-- the entire fix
    },
  });

  // Return 404 (not 403) so we do not confirm the id exists.
  if (!invoice) return res.status(404).json({ error: 'Not found' });

  return res.json(invoice);
});

Now patch API3 at the same time: never trust the request body to decide which fields get written, and never spread the whole object back. Allowlist both directions.

// API3 fix: explicit allowlists, no mass assignment, no over-exposure.
router.patch('/invoices/:id', requireAuth, async (req, res) => {
  // Only these fields may be written by a normal user.
  const { note, dueDate } = req.body; // ignore status, ownerId, isPaid...

  const updated = await db.invoice.updateMany({
    where: { id: Number(req.params.id), ownerId: req.user.id },
    data: { note, dueDate },
  });

  if (updated.count === 0) return res.status(404).json({ error: 'Not found' });

  // Return only safe fields, never the raw row.
  const view = await db.invoice.findFirst({
    where: { id: Number(req.params.id), ownerId: req.user.id },
    select: { id: true, note: true, dueDate: true, total: true },
  });
  return res.json(view);
});

Function-level auth and rate limits

API5 is BOLA's sibling for *operations*: a normal user calling an admin route. The fix is the same shape, check a permission, default-deny, but on the verb/route instead of the object.

// Default-deny role guard. Apply per route.
export const requireRole = (role: string) =>
  (req: Request, res: Response, next: NextFunction) => {
    if (!req.user?.roles?.includes(role)) {
      return res.status(403).json({ error: 'Forbidden' });
    }
    next();
  };

// API5 fix: admin-only deletion is gated by an explicit role.
router.delete('/invoices/:id', requireAuth, requireRole('admin'),
  deleteInvoiceHandler);

API4 (resource consumption) is what turns a slow endpoint into an outage or a five-figure cloud bill. Put limits in front of everything: requests per minute, page size, and body size.

import rateLimit from 'express-rate-limit';

// API4: cap how fast and how big requests can be.
app.use(rateLimit({ windowMs: 60_000, max: 100 })); // 100 req/min/IP
app.use(express.json({ limit: '100kb' }));           // reject huge bodies

// Cap pagination so nobody asks for 1,000,000 rows.
function pageSize(raw: unknown) {
  return Math.min(Number(raw) || 25, 100);
}

Common mistakes that cost hours

1. Checking auth in the gateway only. The gateway proves identity; it almost never knows object ownership. Authorization belongs next to the data.
2. Trusting the client to hide fields. If the mobile app does not show isPaid, the API still accepts it. Allowlist on the server or it is mass assignment.
3. Returning 403 for objects that are not yours. A 403 confirms the id exists. Return 404 so attackers cannot map your id space.
4. Relying on UUIDs as a security control. They slow enumeration but never replace an ownership check.
5. Leaving old API versions running. /v1 with no auth fixes is API9, a back door you forgot you built. Inventory and retire them.
6. Verbose error messages in production. Stack traces and SQL in responses (API8) hand the attacker your schema for free.
7. No rate limit on login or expensive search. That is API2 and API4 working together to enable credential stuffing and DoS.
8. Trusting upstream APIs. A partner's compromised response is your injection vector (API10). Validate it like any user input.

Takeaways

Where to go next

You now have the map and the two fixes that matter most. Build the muscle memory before you ship.

• Solidify the core concept: authentication vs authorization, every API risk above is one of these two applied carefully.
• See the web counterpart for contrast: the OWASP Top 10.
• Find these risks before attackers do with threat modeling, walk each endpoint and ask 'who owns this object'.
• Practice hitting and inspecting raw endpoints in the public API/networking lab.