Broken Access Control: Enforce Permission at the Resource Boundary
Authentication identifies a caller; authorization decides what that caller may do to a resource.
- Author
- absequ
- Published
- Updated
- Category
- Security
- broken access control
- security
- practical guide
Authentication identifies a caller; authorization decides what that caller may do to a resource. Broken access control occurs when the application trusts an identifier, hidden button or broad role without enforcing the actual permission. A legitimate user account can therefore be enough to read or alter another user's data.
On this page
The mental model
Model the subject, action, resource and relevant context explicitly. A manager role may permit viewing a team's records, but not every record in every tenant. Ownership, tenant membership and workflow state often matter alongside roles. A public object identifier is a locator, not a secret authorization token.
A deny-by-default policy makes new resources unavailable unless a rule grants access. Apply the policy on every server entry point, including exports, background jobs and direct API requests. A protected React component or disabled UI button can improve the interface but cannot establish a server-side security boundary.
A practical workflow
Derive user and tenant context from the authenticated session, not from an unchecked client field. Scope the repository query to that context and apply action-specific policy before returning or changing data. Choose an error strategy that avoids unnecessary existence disclosure while remaining diagnosable for authorized operators.
Centralize reusable policy checks without assuming one broad middleware condition is sufficient for every resource. Tests should exercise the real data-access path. An endpoint that correctly rejects one guessed ID may still expose a bulk-list or export path with a different query.
Worked example
function canReadInvoice(user, invoice) {
return user.tenantId === invoice.tenantId
&& (user.id === invoice.ownerId || user.permissions.includes('invoice:read'));
}
// Illustrative policy only: authenticate user and scope data access first.
// Never accept user.permissions from the request body.The comparison is intentionally small enough to reason about. A real implementation must define whether a privileged user may cross tenant boundaries, where the permission list comes from and how revoked access propagates. A catch-all administrator exception can silently defeat otherwise careful isolation.
Create at least two users in different tenants and one privileged test identity. Verify allowed access as well as denied access. Re-run checks through direct URLs, API calls, downloads and any queued work. Test changes in ownership or membership during a workflow instead of assuming authorization remains true forever.
Failure modes and security
Do not fix an authorization defect by replacing sequential IDs with random-looking IDs alone. Unpredictability can reduce easy enumeration, but a leaked identifier must still be unusable by an unauthorized caller. Signed URLs are a different explicit capability design and need limits, expiry and a clear threat model.
Keep security logs useful without recording complete private resources or session credentials. When reporting a defect, use synthetic cross-tenant records and include the precise unauthorized action demonstrated. Revoke exposed access where necessary; a code patch does not undo data already disclosed.
Practice and verification
Choose a document-sharing feature and build an access matrix for owner, collaborator, tenant administrator, unrelated user and unauthenticated visitor. Cover read, update, delete and export separately. Implement tests from that matrix before refactoring policy code. Add one scenario where a collaborator's permission is removed between page load and submission. The mutation must recheck current permission rather than trust that the user once saw an edit button.
References
OWASP authorization guidance — OWASP
OWASP IDOR prevention — OWASP