Broken access control occurs when a system permits an identity to access data or perform an action beyond its authorization. Being signed in is not the same as being allowed to access a particular object, tenant or administrative function.
What it is
Authorization determines whether a caller may perform an action on a resource in a particular context. Authentication establishes who the caller is. Access control fails when the authorization decision is absent, incorrect or inconsistently enforced. A legitimate account can therefore be the starting point for an unauthorized action.
Policy often depends on several attributes: organization membership, role, ownership, object state and the requested operation. A user allowed to view an invoice may not be allowed to edit payment details. A support operator may be permitted to act within one tenant but not across every customer.
How it works
The server receives a request and identifies the acting principal. It then needs to evaluate the requested action against the relevant resource and policy. Checking only that a session exists leaves object and function permissions unresolved. The decision should occur at the point where the protected operation is performed.
Horizontal and vertical boundaries
Horizontal failures cross between peers, such as one customer accessing another customer’s records. Vertical failures cross privilege levels, such as a normal user reaching an administrative action. Real applications can combine both: an operator might exceed the scope of their role within another tenant.
Object, function and property scope
A service may correctly protect a page but fail to protect its export endpoint. It may permit an allowed object update while accepting a field that the user is not allowed to change. Review authorization at the operation and property level, not only at the navigation or page level.
Consistency across paths
The same business action may be available through a web route, an API, a background job or an older interface. If they implement policy differently, the weakest path can undermine the rest. Shared enforcement and explicit tests reduce that inconsistency.
Technical references: OWASP · Authorization · OWASP · REST Security
How attackers use it
An attacker with an ordinary account may attempt to reach another user’s data or a more privileged operation. They do not necessarily need to defeat login or steal an administrator’s password. The opportunity comes from the application accepting a request that the current identity should not be allowed to make.
The impact depends on the permitted action after the check fails. Reading a record, changing ownership and issuing a payment are different outcomes. Document the demonstrated unauthorized behavior and avoid extending it into unsupported claims about every other function.
Warning signs
Look for data from the wrong account, administrative actions available to normal users, inconsistent permissions between interfaces and updates to fields that should be server-controlled. Review authorization logs and business audit records where available.
Test with controlled identities
Use approved test accounts representing different roles and tenants. Define the expected access matrix before testing. A result is meaningful only when the intended policy is known; an intentionally shared object is not an access-control failure merely because two accounts can see it.
Business impact
Access-control failures can undermine tenant isolation and expose sensitive information or business actions at scale. Their seriousness often comes from repeatability across many objects rather than a complex exploit. Trust can be damaged even when the affected users had legitimate accounts.
Recovery can require identifying unauthorized reads or changes, correcting data and reviewing the broader permission model. Logs that record only login success may be insufficient; object and action context are important for determining what happened.
Prevention and remediation
Define permissions explicitly and enforce them on the server for every protected operation. Prefer denying access unless policy grants it. Bind queries and actions to the appropriate tenant and resource scope. Avoid trusting caller-supplied ownership, role or authorization decisions.
Regression checks
- An unauthenticated caller cannot perform an authenticated-only action. - A peer account cannot access another account’s private object. - A lower-privilege role cannot perform an administrative operation. - Restricted fields remain protected during otherwise allowed updates. - Alternate APIs and exports apply the same intended policy. - Authorized users can still complete legitimate workflows.
Treat fixes as policy corrections rather than patches to one visible URL. Review shared components and related operations to understand whether the same missing check appears elsewhere. Preserve controlled evidence of the before and after behavior.
How Ariema detects or handles it
Ariema’s public web and asset context can identify the application and its external entry points. Possible vulnerability context may inform a review when a relevant disclosed component weakness exists.
Determining whether a user can cross an authorization boundary requires application-specific policy and authorized test accounts. The documented Ariema workflow does not establish comprehensive authenticated access-control testing. Teams can connect such assessment evidence with the relevant asset and use follow-up records to track validation of the fix.
Common questions
Do unpredictable identifiers prevent unauthorized access?
They can make identifiers harder to guess, but they do not replace a server-side authorization decision for the requested object and action.
Can a user interface enforce access control?
It can reflect permissions, but the server must enforce them independently. Hidden buttons and disabled fields are not authoritative security boundaries.
Is every permission error a vulnerability?
No. A correctly denied request is expected behavior. A finding needs evidence that an action or data access was allowed contrary to the intended policy.
Sources & further reading
Primary technical references for this guide. Scenarios are illustrative; they are not customer observations.
OWASP · AuthorizationOWASP · REST SecurityOWASP · Authentication Guidance