Broken Access Control: broken access control
It is the No. 1 risk in the Top 10 from OWASP. Broken access control allows a user to access data or perform actions that should not be permitted. A classic issue with often serious consequences.
OWASP Top 10: what are we talking about?
OWASP (Open Web Application Security Project) is a leading community for application security. Its Top 10 ranks the ten most critical risks for web applications, updated across versions. Since 2021, broken access control has ranked first.
Access control is what ensures that everyone can only do what they are authorized to do. When it is poorly designed or incomplete, a user can view another person's data, access administration functions, or modify resources they do not own. A topic at the heart of application security.
Common forms
Insecure direct reference
Changing an identifier in the URL (“id=123” → “id=124”) to access another user's data. The classic IDOR case.
Privilege escalation
Accessing functions reserved for administrators because the user's actual rights are not verified server-side.
Direct URL access
Reaching a “hidden” page by guessing its address, when no control actually restricts access to it.
Poorly protected APIs
Des API endpoints that do not verify authorizations, exposing sensitive data or actions.
Why is it so common?
Access control is cross-cutting: it must be verified on every request, for every resource, server-side. Yet it is tempting to rely on the interface (hiding a button protects nothing) or to forget an endpoint. A single missing check is enough. The consequences range from data leakage to account theft, especially if a privileged account is affected.
The principle: “deny by default”, verify server-side
Good access control is based on a few solid principles: deny everything by default and only authorize explicitly, verify rights server-side on every request (never only in the interface), apply the least privilege, and never trust an identifier provided by the client without an ownership check. These checks are practically validated through a penetration test.
Protect yourself, step by step
Deny by default
Start from closed access and only open explicitly, resource by resource.
Verify server-side
Check rights on every request on the server, never only in the user interface.
Check ownership
Verify that the user is actually entitled to access the requested resource, not just that they are logged in.
Apply least privilege
Limit each role's rights to the strict minimum required, and review permissions regularly.
Log access
Track sensitive access and denials to detect attempted abuse.
Why get support from BCIT?
Role-based tests
We test access from different profiles to reveal real control flaws.
Clear fixes
Recommendations your developers can apply directly, prioritized by impact.
An end-to-end view
From application security to audits, the entire chain.
Not ready to talk yet? Discover our cybersecurity assessment →
Do your users only access what concerns them? 🚀
Let's take 15 minutes to assess the robustness of your access controls and define remediation priorities.
Broken Access Control: broken access control
It is the No. 1 risk in the Top 10 from OWASP. Broken access control allows a user to access data or perform actions that should not be permitted. A classic issue with often serious consequences.
OWASP Top 10: what are we talking about?
OWASP (Open Web Application Security Project) is a leading community for application security. Its Top 10 ranks the ten most critical risks for web applications, updated across versions. Since 2021, broken access control has ranked first.
Access control is what ensures that everyone can only do what they are authorized to do. When it is poorly designed or incomplete, a user can view another person's data, access administration functions, or modify resources they do not own. A topic at the heart of application security.
Common forms
Insecure direct reference
Changing an identifier in the URL (“id=123” → “id=124”) to access another user's data. The classic IDOR case.
Privilege escalation
Accessing functions reserved for administrators because the user's actual rights are not verified server-side.
Direct URL access
Reaching a “hidden” page by guessing its address, when no control actually restricts access to it.
Poorly protected APIs
Des API endpoints that do not verify authorizations, exposing sensitive data or actions.
Why is it so common?
Access control is cross-cutting: it must be verified on every request, for every resource, server-side. Yet it is tempting to rely on the interface (hiding a button protects nothing) or to forget an endpoint. A single missing check is enough. The consequences range from data leakage to account theft, especially if a privileged account is affected.
The principle: “deny by default”, verify server-side
Good access control is based on a few solid principles: deny everything by default and only authorize explicitly, verify rights server-side on every request (never only in the interface), apply the least privilege, and never trust an identifier provided by the client without an ownership check. These checks are practically validated through a penetration test.
Protect yourself, step by step
Deny by default
Start from closed access and only open explicitly, resource by resource.
Verify server-side
Check rights on every request on the server, never only in the user interface.
Check ownership
Verify that the user is actually entitled to access the requested resource, not just that they are logged in.
Apply least privilege
Limit each role's rights to the strict minimum required, and review permissions regularly.
Log access
Track sensitive access and denials to detect attempted abuse.
Why get support from BCIT?
Role-based tests
We test access from different profiles to reveal real control flaws.
Clear fixes
Recommendations your developers can apply directly, prioritized by impact.
An end-to-end view
From application security to audits, the entire chain.
Not ready to talk yet? Discover our cybersecurity assessment →
Do your users only access what concerns them? 🚀
Let's take 15 minutes to assess the robustness of your access controls and define remediation priorities.