top of page

Understanding API Broken Access Control: A Beginner's Guide


In the world of web application security, few threats are as dangerous — and overlooked — as Broken Access Control (BAC). It’s not flashy like SQL injection or trendy like zero-days, but when access control breaks, the entire system can unravel. At its core, BAC happens when a system fails to properly enforce who can do what. The results? Users access data or actions they were never supposed to.


Let’s break down what BAC really is, the two main types of privilege escalation it enables, and why it matters so much.


What is Broken Access Control?


Access control is how a system determines what resources a user is allowed to access or modify. It’s the digital equivalent of having the right key for the right door.


Broken Access Control happens when:

  • Users can perform actions outside of their intended permissions.

  • Access restrictions can be bypassed or are missing altogether.

  • Roles and ownership aren’t properly validated by the backend.

These flaws don’t just lead to bugs — they open the door to data leaks, privilege escalation, and full system compromise.


Scenario: A Hidden API with a Simple Flaw


A company’s web application includes a hidden API designed exclusively for two high-profile users, Billy and Kyne, to perform specific administrative tasks. The API is accessed via a POST request to an endpoint like:


POST /api/admin/reports

The functionality does not appear on the user interface, making it seemingly secure.

However, there is a major oversight: the application does not check if the user making the request is actually Billy or Kyne. Any authenticated user can send a POST request to the endpoint and execute these restricted tasks.


How the vulnerability unfolds:


  • Discovery of the API:

    A curious user, “Alex,” notices unusual traffic in the browser’s developer tools or intercepts requests using tools like Burp Suite. Through exploration, Alex discovers the hidden POST API endpoint:


POST /api/admin/reports

  • Fuzzing the Endpoint:

    Alex experiments by crafting requests to the endpoint, adjusting headers, and modifying payloads. To their surprise, the server responds positively and grants access to reports meant only for Billy and Kyne.


  • Data Extraction:

    Alex writes a script to automate requests to the API, downloading sensitive data that was never intended for their eyes.


  • No UI, No Problem:

    The absence of a UI interface for this functionality doesn’t deter Alex. Tools like Postman or cURL allow them to interact directly with the API, bypassing the need for a front-end interface.


Why This Happened


The root cause of this issue lies in Broken Access Control. Specifically:

  • The API endpoint does not validate the user’s role or permissions before processing the request.

  • The application relies solely on obscurity (no UI) to hide the functionality, assuming users wouldn’t find or use the endpoint.


Types of Privilege Escalation


1. Vertical Privilege Escalation



“User becomes admin.”


This is when a lower-privileged user gains access to functions or data reserved for higher-privileged roles. For example:

  • A regular user accessing admin-only dashboards via direct URL manipulation.

  • An API that doesn’t validate user roles properly and allows normal users to perform admin actions like deleting other users or changing system settings.

Impact: Total loss of system control. Attackers can override permissions, exfiltrate sensitive data, or disrupt operations.


2. Horizontal Privilege Escalation


“User becomes another user.”

This involves a user accessing resources belonging to another user with the same privilege level. Examples include:

  • Changing the user_id in a URL or API request to access another person’s profile, orders, or messages.

  • Downloading someone else’s invoice by guessing the file path.

Impact: Data leakage, privacy violations, and unauthorized transactions. Especially dangerous in healthcare, finance, or education apps where sensitive personal data is involved.


Real-World Consequences


Broken access control has serious consequences:


  • Compliance Violations: Exposing personal or financial data can lead to GDPR, HIPAA, or PCI-DSS fines.

  • Brand Damage: Users lose trust when their data is compromised.

  • System Takeover: In extreme cases, attackers can chain horizontal and vertical privilege escalation to completely take over the application.


Why Does BAC Happen?


1. Lack of Role Validation


Issue: Applications fail to verify the roles or privileges of users before allowing access to sensitive resources or functionalities.

Example: An API endpoint meant for administrators does not check if the requester has admin privileges, allowing any authenticated user to access it.


2. Over-Reliance on Client-Side Enforcement


Issue: Access controls are implemented on the client-side, such as in JavaScript or HTML, instead of on the server. This allows attackers to bypass restrictions by manipulating requests.

Example: A hidden button or menu is simply not shown to unauthorized users, but the endpoint it triggers is still accessible.


3. Improper Endpoint Security


Issue: API or web endpoints do not enforce proper authorization, assuming that obscurity (e.g., lack of a UI) will prevent access.

Example: A mobile app makes requests to hidden endpoints, but any user can discover and access them using tools like Burp Suite or Postman.


4. Failure to Implement the Principle of Least Privilege


Issue: Users are granted broader access rights than necessary, increasing the risk of unauthorized actions.

Example: A user with read-only permissions accidentally receives write or execute privileges.


5. Inadequate Testing and Security Reviews


Issue: Developers may not thoroughly test access controls, especially on hidden APIs or rarely used features.

Example: QA focuses only on UI functionality, missing back-end vulnerabilities.


How to Prevent Broken Access Control


  1. Deny by default. Only allow access to authenticated and authorized users.

  2. Implement role-based access control (RBAC) on the server side — never trust the front-end.

  3. Validate ownership of every object (e.g., check that a user owns a resource before showing or modifying it).

  4. Test for privilege escalation using role-switching and IDOR testing.

  5. Log and monitor access attempts — flag and block unusual activity.


Conclusion


Broken Access Control isn’t theoretical — it’s the #1 issue in the OWASP Top 10 2021 for a reason. Whether it’s horizontal or vertical privilege escalation, the cost of ignoring BAC is high. Developers must assume users will try to break the rules and build systems that enforce permissions strictly and consistently on the backend.


Security isn’t about trusting users — it’s about verifying limits. Always.


Comments


bottom of page