Authorization, Past the If-Statement

The authentication deep dive ended on a clean line: authentication answers who are you, authorization answers what are you allowed to do. Auth gets all the attention because it's where the cryptography is, but authorization is where the breaches are. "User A could see User B's invoices" is not a login bug — A logged in perfectly well. It's an authorization bug, and it's the single most common serious vulnerability in real applications, because it hides in plain sight as ordinary-looking business logic.

The simplest version, and where it rots

You start with one check, and it's fine:

if (user.role !== "admin") return res.status(403).end();

Then the rules grow. Editors can edit but not delete. Users can edit their own posts. Billing admins can see invoices but not change roles. Six months later, the same permission is checked in fourteen handlers, each slightly differently, and one of them — the new endpoint someone added in a hurry — forgot the check entirely. That forgotten check is the breach.

The rest of this dive is about getting the decision out of the handlers and into one place — and about choosing a model that can express your actual rules.

The three models: RBAC, ABAC, ReBAC

These sound like jargon, but each is just a different answer to "what does a permission depend on?"

The progression is about expressiveness. Most apps start with RBAC and should — it's the easiest to reason about and audit. You reach for ABAC when decisions depend on the data (amounts, ownership, time), and for ReBAC when access flows through relationships and nesting (sharing, hierarchies). They compose: a real system is often "RBAC for coarse roles, plus attribute checks for the fine-grained 'is it yours and under the limit' rules."

Centralize the decision

Whatever model you pick, the structural fix is the same: the decision "is this allowed?" comes from one component, and every handler asks it. The handler's job is to enforce, not to decide.

This is the policy enforcement point (PEP) vs policy decision point (PDP) split. The handler is the enforcement point — it calls can(user, "delete", invoice) and returns 403 if denied. The decision point is the one function (or service, or policy file) that holds all the rules. Now "who can delete an invoice?" has exactly one place to read, one place to change, and one place to test.

// Handler only enforces:
async function deleteInvoice(req, res) {
  const invoice = await invoices.byId(req.params.id);
  if (!invoice) return res.status(404).end();
  await authorize(req.user, "invoice:delete", invoice); // throws 403 if denied
  await invoices.delete(invoice.id);
  res.status(204).end();
}

Every endpoint follows the identical shape: load the resource, authorize, act. The check can no longer be subtly different in each handler, and a code reviewer can scan for "does this handler call authorize before mutating?" as a single, mechanical rule.

The bug that matters most: missing object-level checks

There's a hierarchy of authorization, and most breaches happen at the bottom of it:

1. Function-level: can this user call this endpoint at all?

   "Is this user an admin?" The coarse check. Easy to get right, and the one people remember.

2. Object-level: can this user act on THIS specific record?

   "Is this invoice theirs?" This is the one that gets forgotten, and forgetting it is the classic IDOR (Insecure Direct Object Reference) bug: the endpoint checks you're a logged-in user, fetches the invoice by the ID in the URL, and hands it over — without checking the invoice belongs to you. Change the ID in the URL, read someone else's data.

3. Field-level: can this user see THIS column of this record?

   "Can a support agent see the customer's name but not their card number?" The finest grain, often handled by shaping the response per role.

Multi-tenancy: when one bug leaks everyone

If your app serves multiple customers (tenants) from one database — the normal SaaS shape — authorization gets a hard floor: no query may ever cross a tenant boundary. Tenant A must never, under any bug, see tenant B's rows. A single missing WHERE tenant_id = ? is not a small bug here; it's a cross-customer data breach.

You don't want this to depend on every developer remembering the tenant_id filter on every query. The defenses, strongest last:

The confused deputy: when your own server is the leak

A subtler class: the confused deputy. Your server holds powerful credentials — a database connection, an internal API key, an S3 token — and acts on behalf of a user. If you let the user's input steer that power without re-checking it against their permissions, your trusted server becomes their deputy, using its authority to do something they couldn't do themselves.

The classic shape: an endpoint takes a file key and streams it from S3 using the server's S3 credentials. The server is allowed to read every file; the user is not. If the endpoint doesn't verify this user may read this file before using its own powerful S3 access, the user passes any key and the server dutifully fetches it. The server wasn't tricked into revealing its credentials — it was tricked into using them on the attacker's behalf. The fix is always the same: authorize the user's right to the resource before you spend the server's authority on it.