API security: authentication, authorisation and abuse prevention

What is broken object-level authorisation?

An endpoint that returns or modifies a resource based on an id supplied by the caller, without checking that the caller may access that resource.

// Vulnerable: any authenticated caller can read any order
app.get("/orders/:id", requireAuth, async (req, res) => {
  res.json(await db.order.findUnique({ where: { id: req.params.id } }));
});

// Correct: scope the query to the caller's organisation
app.get("/orders/:id", requireAuth, async (req, res) => {
  const order = await db.order.findFirst({
    where: { id: req.params.id, organisationId: req.user.organisationId },
  });
  if (!order) return res.status(404).end();
  res.json(order);
});

• Test it directly: authenticate as user A and request user B's resource ids.
• Sequential integer ids make enumeration trivial — use UUIDs, but never rely on them as security.
• Apply the same check to nested resources, bulk endpoints, exports and search.
• Return 404 rather than 403 where existence is itself sensitive information.

How should authentication be handled?

• Verify the signature, algorithm, issuer, audience and expiry on every token — not just the signature.
• Never accept credentials in a query string; they end up in logs and referrer headers.
• Scope API keys to specific permissions and specific resources, and make rotation self-service.
• Keep token lifetimes short and refresh explicitly.

How do you prevent data over-exposure?

1. 1Define explicit response shapes. Returning the whole database row leaks internal fields, password hashes and audit columns.
2. 2Filter at the query, not in the client — 'the UI does not display it' is not a control.
3. 3Prevent mass assignment: accept only an explicit list of writable fields from the request body.
4. 4Never accept role, tenant, price or status from the client without server-side authorisation.
5. 5Apply field-level permissions where different roles see different subsets.

// Mass assignment: a caller can set role: "admin"
await db.user.update({ where: { id }, data: req.body });

// Safe: parse to an explicit shape first
const data = updateProfileSchema.parse(req.body);  // name, avatarUrl only
await db.user.update({ where: { id }, data });

How do you prevent abuse?

• Rate limit by authenticated identity, with tighter limits on unauthenticated endpoints.
• Cap request body size and pagination limits — an uncapped limit parameter is a denial-of-service vector.
• For GraphQL, enforce query depth and complexity limits and consider disabling introspection publicly.
• Add per-account concurrency limits for expensive operations such as exports.
• Monitor for enumeration patterns: many 404s from one identity is a signal.
• Return consistent timing on authentication paths so responses do not leak account existence.

What should be in an API security review?

1. 1Enumerate every endpoint, including undocumented and legacy ones. You cannot secure what nobody remembers.
2. 2For each: who may call it, what it returns, what it can modify.
3. 3Test object-level authorisation with two accounts on every resource-scoped endpoint.
4. 4Test mass assignment by adding unexpected fields to request bodies.
5. 5Verify rate limits actually apply, including behind a CDN.
6. 6Check that errors do not leak stack traces, queries or internal hostnames.