What is Broken Access Control?

Broken access control is a collective term for authorization flaws. An application may correctly recognize who a user is, yet fail to check whether that user is permitted to read a record, change a setting or call an administrative function. This is different from authentication: a valid login does not automatically grant access to every resource.

A typical example is an invoice URL containing a numeric ID. If changing the ID reveals another customer's invoice, the server has trusted user-controlled input instead of enforcing ownership. This specific pattern is also known as IDOR.

How does broken access control arise?

Common causes include missing server-side checks, inconsistent authorization rules, overly broad roles and endpoints that are hidden in the interface but remain callable. The impact ranges from viewing individual records to changing privileges or taking over an entire application.

How can it be prevented?

• - Deny access by default and verify permissions on every request, not only in the frontend.
• - Centralize authorization rules and test horizontal as well as vertical privilege boundaries.
• - Use non-predictable identifiers as an additional hurdle, but never as a replacement for authorization.
• - Log rejected access attempts and review sensitive workflows in a penetration test.

Code example: bind authorization to object and action

Vulnerable: every authenticated user can reach the function.

$document = Document::findOrFail($id);
return response()->download($document->path);

Safer: a central policy decides for the specific object.

$document = Document::findOrFail($id);
$this->authorize('download', $document);

return response()->download($document->path);

public function download(User $user, Document $document): bool
{
    return $user->tenant_id === $document->tenant_id
        && $user->hasPermission('documents.download');
}

The policy must cover every access path, including API, export, preview and background jobs. Loading through a tenant relationship can additionally keep foreign objects out of the normal data path altogether.

Horizontal and vertical privilege escalation

Horizontal escalation lets a user access data belonging to another user with a comparable role, such as another customer's invoice or support ticket. Vertical escalation crosses a privilege boundary: a normal account can invoke an administrative function or change permissions. Both forms may also cross tenant boundaries. In a SaaS application, authorization therefore has to verify the tenant as well as the user and requested object.

A typical attack path

An attacker first records requests for a permitted action and then changes object IDs, role parameters, HTTP methods or endpoints not visible in the interface. If the server returns somebody else's data or performs the action, the server-side authorization decision is missing. Hiding a button does not help: browsers, scripts and proxy tools can still send the request directly. A URL that merely looks unpredictable is not an access-control check either.

How is broken access control tested?

A meaningful test uses multiple accounts, roles and, where applicable, tenants. The tester builds a matrix of objects and permitted actions, then repeats requests with identities, IDs and functions exchanged. Reading and editing are not the only cases: deletion, export, approval, sharing, search results and file downloads may enforce different rules. Automated scanners detect simple patterns, while business rules almost always require manual analysis.

What makes authorization robust?

Permissions should be centralized, denied by default and checked on the server for every request. The decision must consider the user, role, tenant, requested object and action. Integration tests should cover negative cases explicitly. Logging helps identify repeated rejected requests. Random identifiers and network separation are useful additional barriers; neither replaces the authorization decision.