Who are you, and what may you touch?

Authentication answers "who are you?" Authorisation answers "are you allowed to do this, to this thing?" Frameworks give you strong help with the first: a login library, a session or token check, a guard that rejects anonymous calls. The second depends on your business rules, so no framework can write it for you. That gap is where most of these bugs live.

Every request that touches data needs three answers, in this order:

• Who is calling? Identity comes from a verified session or token, never from something the client says about itself (you met session and token basics in Identity: passwords, MFA and passkeys; Authentication, sessions and tokens goes deeper).
• May this kind of caller use this function at all? A shop owner may view invoices; only finance staff may change a credit limit. This is function-level access control.
• May this caller touch this particular object? Invoice 9042 belongs to shop 88, so the owner of shop 41 may not read it. This is object-level access control, and it is the one most often missing.

The OWASP Top 10 is a list, updated every few years from data on real applications, of the most important web application risks. In the 2021 edition, broken access control moved up from fifth place to first, and it had more occurrences than any other category in OWASP's data. The 2025 edition keeps it first, and folds in server-side request forgery, which had its own place in 2021. The reasons are structural. Each endpoint needs its own object check, so one forgotten line opens one door. Automated scanners can't tell which data belongs to whom. And most teams test with one account, so the bug never shows up in testing.

Insecure direct object references in the Partner app

The course's practice copy of the Partner app has an invoice endpoint. A shop owner taps "Download invoice" and the app calls GET /partner/invoices/9042. The controller loads the invoice by its id and returns it. Here is the vulnerable pattern, in a few lines:

// BEFORE: the route is behind login, but any logged-in shop gets any invoice
@UseGuards(AuthGuard)
@Get(':id')
async getInvoice(@Param('id', ParseIntPipe) id: number) {
  const { rows } = await this.db.query('SELECT * FROM invoice WHERE id = $1', [id]);
  return rows[0];
}

This is an insecure direct object reference (IDOR). The input class is simple: a valid, logged-in user changes an identifier in the path, query string or body to one that belongs to someone else. With sequential ids, the neighbouring numbers are other shops' invoices. MITRE's weakness list calls it CWE-639, authorisation bypass through a user-controlled key.

From the reviewer's side, look for these shapes in a pull request:

• A route parameter or body field with "id" in its name that goes straight into a query, with nothing in that query or after it that mentions the caller.
• A tenant identifier, such as shopId, read from the request (path, query string, body or a header) instead of from the verified session.
• A guard that checks only that the user is logged in, on a route that returns one customer's data.
• List and export endpoints. They often get a filter by tenant, while the single-item and download routes next to them don't.

From the fixer's side, the fix is to make the query itself answer the ownership question. Take the shop from the session, add it to the WHERE clause, and return the same 404 for "not yours" as for "does not exist". Returning 404 instead of 403 here means a prober can't even confirm that invoice 9043 exists. Both are acceptable; pick one and use it everywhere.

The fix pattern: deny by default, check every object on the server

One-off if statements in each controller are how this bug comes back six months later. The fix that lasts is a pattern the whole codebase follows:

• Deny by default. A route with no declared access rule is refused, not open. A role the policy doesn't know gets nothing. A missing field (no shop id on the user, no shop id on the record) is a deny, never a match.
• Identity and tenant come from the server. The caller's user id, role and shop come from the verified session or token. A shopId in the request is, at most, a filter that must be checked against what the caller may see.
• Scope every query by tenant. A tenant is the customer whose data must stay separate, here one partner shop. List queries carry WHERE shop_id = $caller; single-object reads either do the same or load the object and pass it through a policy function before returning it.
• Central policy functions. Write canReadInvoice(user, invoice) once, test it hard, and call it everywhere. A reviewer then checks one function instead of forty controllers.
• A second layer in the database. PostgreSQL row-level security (RLS) can filter rows by the shop set for the current transaction, so a query that forgets its WHERE clause still returns only that shop's rows.

@UseGuards(AuthGuard)
@Get(':id')
async getInvoice(@Param('id', ParseIntPipe) id: number) {
  const { rows } = await this.db.query('SELECT * FROM invoice WHERE id = $1', [id]);
  return rows[0];   // anyone logged in gets any invoice
}

@Policy('invoice:read')                       // function level: which roles may call this
@Get(':id')
async getInvoice(@Param('id', ParseIntPipe) id: number, @Req() req: AuthedRequest) {
  const invoice = await this.invoices.findById(id);
  // object level: one tested policy function, caller taken from the session
  if (!invoice || !canReadInvoice(req.user, invoice)) {
    this.audit.denied(req.user, 'invoice:read', id); // feeds detection
    throw new NotFoundException();                   // same answer as "no such invoice"
  }
  return invoice;
}

Row-level security deserves a warning. By default, the role that owns a table and any role with the bypass attribute are not filtered by its policies, and many applications connect as the owner. Use FORCE ROW LEVEL SECURITY or connect as a separate, non-owner application role. And set the caller's shop per transaction, not per connection, or a pooled connection carries the last request's shop into the next one. The Build it section shows both.

Function-level checks, mass assignment and escalation

Object checks stop one shop reading another's data. Two other gaps are just as common.

Function-level gaps. The Partner app's back office has PATCH /admin/shops/:id/credit-limit. The button is only shown to finance staff, so nobody added a role check. But hiding a button is a user interface choice, not a control: anyone who can send an HTTP request can call the route. Every route needs a declared rule on the server, and admin routes should live behind a separate guard, ideally a separate path prefix that is easy to audit.

Mass assignment. A profile update does Object.assign(shop, body) or passes the whole request body to the ORM. The form only sends a display name and phone number, but the caller can add creditLimitCents or role to the body, and the server saves them. The fix is an allowlist: a DTO (data transfer object) that names the fields a caller may set, and NestJS's ValidationPipe set to strip or reject anything else. OWASP's Mass Assignment Cheat Sheet covers the same idea for other frameworks.

Both lead to privilege escalation, which comes in two directions. Horizontal escalation means the same role, someone else's data: shop 41 reading shop 88's invoices. Vertical escalation means a higher role's powers: a shop owner raising their own credit limit, which only finance may do. Write the rules down as a matrix before you write code. It becomes your policy function and your test plan.

Prove it with tests, and watch for abuse

Access control bugs survive because the happy path works. Every test logs in as one shop and reads that shop's data. The fix is to make two of everything part of the test setup: two shops, each with an owner and a staff account, a sales rep assigned to one of them, and a finance admin. Then turn the matrix into tests. For each route and role, assert the allowed case returns 200 and the forbidden case returns your chosen 404 or 403. Run them in CI, so a new route without a rule fails the build.

Unit-test the policy functions with the edge cases: missing shop id, an empty assigned list, an unknown role, a null record. Those are exactly the inputs where hand-written checks fail open, as in undefined == undefined being true. In manual testing, an intercepting proxy shows a tester every request the app makes, so they can repeat a request with the second account's session. You will use one in the sandbox in Attacking web applications.

Detection is the safety net for the bug you haven't found yet. Log every authorisation decision in a structured form: who (user id, role, shop), what (action, object id, the object's shop) and the result. Then watch for patterns that normal use doesn't make:

• One account requesting many different invoice ids in a short time, especially consecutive ones.
• A burst of 403 or 404 responses on object routes from one account or one IP address.
• Successful reads where the object's shop differs from the caller's shop, outside finance and the rep's list. If you log both shop ids, this is a direct sign the check is missing somewhere.
• Calls to admin routes from non-admin roles, even denied ones.

Many denials on the same id usually mean a broken link in the app, while denials across many different ids look like someone stepping through numbers. Writing detections turns patterns like these into alert rules.