Access Control: Roles, Ownership, and Default-Deny

Authentication tells you who the request came from; access control decides what that person may actually do. This tutorial covers the models you'll use to express that decision — ownership, roles, policies — plus the three principles that keep any model safe: least privilege, default-deny, and enforcement at the boundary. By the end you can look at any API endpoint and say exactly which checks must run before a request is allowed.

Table of Contents

• Access Control vs Authorization
• Three Core Models
• What the Identity Carries
• Rule 1: Least Privilege
• Rule 2: Default Deny
• Rule 3: Enforce at the Boundary
• Roles (RBAC) Up Close
• Checking a Role in Code
• Per User vs Per Action
• Ownership and IDOR
• Privilege Escalation: Your API's Worst Bug
• Defense in Depth
• The Standard Check Sequence
• Best Practices

Access Control vs Authorization

Access control and authorization both answer "what may this identity do?" — the difference is scope. Authorization is the moment your app checks one permission. Access control is the whole system that decides who can reach what: users, roles, policies, and the rules that govern them. Think of authorization as the individual check at each door, and access control as the building's entire plan of doors and keys.

A typical system does both: identify a user (authentication), then decide what that user may do (access control), and, behind each action, check one specific permission (authorization).

Three Core Models

You'll see three dominant ways to express "who can do what." They build on each other:

For most FDE work, RBAC plus ownership covers almost everything. Reach for ABAC only when you need finer rule logic, such as "allowed only between 9–5, and only for assets over $5k."

What the Identity Carries

Every identity carries a set of attributes: who you are, the group you belong to, the roles you hold, perhaps the account you act for. Authentication binds these attributes to your identity; access control reads them back and decides. A permission check is really asking: "do the attributes of this identity satisfy this rule?"

Rule 1: Least Privilege

You met this in Tutorial 1; here it is in access-control dress: grant the minimum permission that makes the action work. A viewer reads, an editor edits, an admin deletes. Separate, scoped permissions beat one wide god-permission, because a compromised small role stays small. Shrinking scope shrinks the blast radius of any leak.

Rule 2: Default Deny

Start with everything denied, then add allowances only where you need them. A hidden endpoint no one remembered to open is safe under default-deny; under default-allow it silently serves data. Default-deny turns "I forgot" into "no access," not "no leak."

Best Practice: every new endpoint and permission starts closed. Turn it on explicitly, then test it.

Rule 3: Enforce at the Boundary

An access check that only lives inside your UI, or that one helper you forget to call somewhere, is easy to bypass. Enforce at the boundary: a single middleware that runs on every request before the handler. Then there is no unguarded path, and a missing check in one handler can't silently expose its data.

Roles (RBAC) Closer

Role-based access control is the workhorse. Assign each user one or more roles, and each role bundles a set of permissions. Nobody gets a raw permission in a vacuum; they get a role that implies it. This makes granting ("promote Alice to admin") and revoking ("remove Bob from the team") a one-line change:

Alice → role: data_analyst → permissions: [read_reports, view_dashboard]
Bob   → role: team_admin   → permissions: [read_reports, manage_users]

Checking a Role in Code

Your backend stores the user's roles and checks them at each handler. Usually a role gate and an ownership gate both run:

ROLES = {"alice": {"team_admin"}, "bob": {"data_analyst"}}

def export_report(user, report_id, ROLES, OWNERS):
    if not ({"data_analyst", "team_admin"} & ROLES[user]):   # role gate
        raise PermissionError("role not allowed")

    if user not in OWNERS.get(report_id, set()):             # owner gate
        raise PermissionError("not the owner")

    return run_export(report_id)

Explanation: the request must pass both gates. The role gate admits analysts and admins; the ownership gate then guarantees the user is the owner. Two independent models that both can reject — that's access control done right, not a bug.

Per User vs Per Action

Two knobs you will set constantly:

• Per user: this user owns this resource. Used for data — "invoice 42 belongs to Alice."
• Per action (verb): this kind of action is permitted or not. Used for verbs — "deleting requires the archive permission."

A teammate who can view a folder may still be blocked at the "delete" action. Combine the knobs to get "only Alice (owner) may delete her invoice" — the classic enterprise shape.

Ownership and IDOR

In Tutorial 1 you met IDOR (Insecure Direct Object Reference) — the leak where code trusts an id from the request. The access-control fix is the same, now written as a standing rule:

def get_invoice(requesting_user, invoice_id, OWNERS):
    allowed = OWNERS.get(invoice_id, set())
    if requesting_user not in allowed:
        raise PermissionError("not an owner")
    return fetch_invoice(invoice_id)

Why it must be a rule, not an afterthought: the moment any endpoint accepts an id and returns a record, someone with no gate can pass another person's id and read it. Make ownership the default in your data layer, and IDOR disappears.

Privilege Escalation — Worst-Value Bug

Privilege escalation is an attacker gaining access they should not have: a normal user becoming the admin, or user A reading user B's data. It is almost always an authorization failure — a missing ownership check or an overly trusting role — not a clever technical exploit. This is the highest-severity class of bug in most business software.

Why it's invisible: the happy path works. Only the unhappy path (a caller passing an unowned id) reveals it. The earliest disaster in real apps is usually this and not the crypto. Red-team your endpoints: call them with a normal user's token against someone else's resource.

Defense in Depth

Never rely on a single gate. Layer them so that if one fails, the others stand: a DB user with only SELECT, a network rule that hides the DB, an endpoint that still checks ownership, and logs that record every request. "One wall" is a security smell — make layers the norm.

The Standard Check Sequence

Every request that returns data passes these, in this order:

1. Authenticate the identity (Tutorial 1).
2. Authorize the action type (has the role/permission?).
3. Bind to the exact resource (does the user own the object?).
4. Policy (ABAC / enterprise rules, Tutorial 8).

If any step stops, return 401 or 403. Keep steps 2 and 3 both — step 3 is what slays IDOR.

Encapsulation of Entitlement

Keep the rule logic in one place (a policy module), not scattered across handlers. Handlers then declare their requirement ("requires ownership + archive"), and the shared gate enforces it. This is the practical way to guarantee enforce-at-the-boundary without repeating the same check thirty times.

Best Practices

• Default deny. Start closed; open only what you need.
• Enforce at the boundary. One check on every request, no unguarded handlers.
• Bind resources to owners. This removes the IDOR class entirely.
• Add policy (ABAC) only when RBAC + ownership is not enough.
• Least privilege. The smallest role that works.
• Audit. Log user, role, resource, and verb for sensitive requests.