Access Control
// Definition
The set of policies and mechanisms that decide which users or processes can view, create, modify, or delete resources. Access control sits above authentication (confirming identity) and is implemented through models such as RBAC, ABAC, or access-control lists. Failures — privilege escalation, horizontal movement between user accounts, bypassing function-level checks — are consistently the most widespread class of security vulnerability. Test strategy: exercise every protected action with at least three privilege levels: the allowed role, a lower-privileged role, and unauthenticated.
// Related terms
Authorization
The process of determining what an authenticated caller is permitted to do. Where authentication answers "who are you?", authorization answers "what are you allowed to do?" Common models include role-based access control (RBAC), attribute-based access control (ABAC), and scope-based delegation (OAuth). Testing authorization means verifying that every protected action enforces its policy — including negative cases where a lower-privileged user is explicitly denied access rather than silently downgraded.
Permission
A discrete, named right to perform a specific action on a resource — for example, orders:read, users:delete, or admin:manage-billing. Permissions are the atomic unit of access control; roles (RBAC) are collections of permissions granted to a group. In testing, each permission must be verified in isolation: a user with orders:read but not orders:write should receive a 403 on write operations, not a 200 or a 404 that obscures the enforcement failure.
RBAC
Role-Based Access Control — a permission model where access rights are assigned to roles, and users inherit permissions by belonging to one or more roles. A `viewer` role can read resources; an `admin` role can create, update, and delete. In API testing, RBAC tests verify that each role can reach only the endpoints it should: a viewer calling `DELETE /content` should get a 403, not a 200. Broken access control at the object and function level is consistently in the OWASP API Security Top 10.
IDOR (Insecure Direct Object Reference)
A vulnerability where an application exposes internal object identifiers — database primary keys, file paths, account numbers — and fails to verify that the caller is authorised to access the referenced object. Example: user A requests GET /api/orders/1042; simply changing the ID to 1043 returns another user's order. IDORs are consistently one of the most prevalent API vulnerabilities (OWASP API Security Top 10: Broken Object Level Authorization). Testing: for every endpoint that accepts a resource ID, verify with a second authenticated account that it cannot access the first account's resources.