Broken access control is an application-security failure in which a system does not correctly enforce what an authenticated user, service, or tenant should be allowed to access or change.
Broken access control is an application-security failure in which a system does not correctly enforce what a user, service, or tenant should be allowed to access or change. In plain language, it means the application knows someone is signed in but does a poor job checking whether that caller should actually be allowed to perform the requested action.
Broken access control matters because access mistakes often expose the most sensitive parts of an application: customer records, administrator functions, payment actions, private documents, or internal management APIs. When permission checks fail, the impact can be severe even without complicated exploitation.
It also matters because access-control logic is rarely confined to one place. It often spans frontend flows, backend services, API endpoints, tenant boundaries, role assignments, object ownership checks, and workflow approvals. A gap in one layer can undermine the rest of the model.
Broken access control appears in admin dashboards, public APIs, multi-tenant SaaS products, document-sharing systems, internal approval workflows, and mobile backends. Teams look for it during code review, design review, application testing, and incident investigation.
It connects closely to Authorization, Role-Based Access Control, Attribute-Based Access Control, Least Privilege Access, Insecure Direct Object Reference, and API Security.
It is one of the most important application risks because it can directly affect both confidentiality and integrity. Data can be read by the wrong party, but just as importantly, approvals, records, or settings can also be changed by the wrong party.
A user in a multi-tenant billing portal modifies a request so it references another customer’s invoice identifier. The system verifies that the request comes from a signed-in user but never checks tenant ownership for that specific invoice. The result is unauthorized access to another customer’s data even though the caller did authenticate successfully.
Broken access control is not the same as failed Authentication. Authentication answers who the caller is. Access control answers what that authenticated caller is allowed to do, see, edit, approve, or download.
It is also broader than one role-mapping mistake. The underlying problem may involve missing ownership checks, hidden administrative routes, inconsistent API enforcement, unsafe defaults, or the mistaken assumption that a hidden button in the frontend is a real permission boundary.
Broken access control is also not limited to human users. Service accounts, automation, and backend jobs can be over-permitted too, which can create equally serious exposure.