HIGH Authorization

Broken Access Control in APIs

What is Broken Access Control?

Broken Access Control (BAC) occurs when an application fails to properly enforce permissions, allowing users to access data, functionality, or resources they shouldn't have access to. In APIs, this vulnerability manifests when authorization checks are missing, improperly implemented, or can be bypassed.

Unlike authentication (verifying who you are), authorization determines what you're allowed to do. A BAC vulnerability means the system incorrectly grants access based on roles, permissions, or ownership rules. Common examples include:

  • Viewing another user's data by modifying resource IDs in API requests
  • Accessing administrative functions without proper privileges
  • Escalating privileges by tampering with authorization tokens
  • Accessing system endpoints that should be restricted

The vulnerability exists when the API trusts client-side data or fails to validate permissions on the server side. Even with perfect authentication, broken access control can expose sensitive information and functionality to unauthorized users.

How Broken Access Control Affects APIs

In API contexts, broken access control can have severe consequences because APIs often serve as the backend for multiple clients (web apps, mobile apps, third-party integrations). A single vulnerability can expose data across all platforms simultaneously.

Common attack scenarios include:

  • Resource ID manipulation: An API endpoint like /api/users/123/orders returns orders for user 123. If the API doesn't verify that the authenticated user owns user 123, an attacker can simply change the ID to access other users' data.
  • Privilege escalation: API endpoints meant for administrators (like /api/admin/users) might be accessible if role checks are missing or can be bypassed by modifying role claims in JWT tokens.
  • Business logic flaws: APIs that don't properly validate state transitions or ownership can allow actions like approving your own requests, accessing deleted resources, or performing actions outside your permission scope.
  • Metadata exposure: APIs might expose internal system information, configuration details, or debugging endpoints that reveal sensitive infrastructure details.

The impact ranges from data breaches and privacy violations to complete system compromise, depending on what functionality the attacker can access.

How to Detect Broken Access Control

Detecting broken access control requires systematic testing of authorization mechanisms. Here are the key approaches:

  • Manual testing: Create test accounts with different permission levels, then attempt to access resources and functionality across those boundaries. Try modifying resource IDs, user IDs, and permission claims in tokens.
  • Automated scanning: Tools like middleBrick perform automated black-box scanning that tests for authorization flaws without requiring credentials. The scanner modifies request parameters to probe for access control weaknesses.
  • Code review: Examine authorization logic to ensure every endpoint validates permissions against the authenticated user's actual role and ownership rights.
  • Specification analysis: Review OpenAPI specs to identify endpoints that should be protected but lack proper authorization annotations.

middleBrick specifically tests for broken access control by:

  • Modifying resource identifiers in API requests to test if users can access others' data
  • Testing privilege escalation by attempting administrative actions with standard user permissions
  • Analyzing response data to identify information disclosure across user boundaries
  • Checking for missing authorization headers or token validation

The scanner reports findings with severity levels and provides specific remediation guidance for each detected issue.

Prevention & Remediation

Preventing broken access control requires defense-in-depth approaches at both the code and architecture levels:

1. Implement Proper Authorization Checks

// INSECURE - missing authorization check
app.get('/api/users/:userId/orders', (req, res) => {
  const orders = getOrdersByUserId(req.params.userId);
  res.json(orders);
});

// SECURE - verify ownership
app.get('/api/users/:userId/orders', authenticate, (req, res) => {
  if (req.user.id !== parseInt(req.params.userId)) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  const orders = getOrdersByUserId(req.params.userId);
  res.json(orders);
});

2. Use Role-Based Access Control (RBAC)

const permissions = {
  'user': ['read:self', 'update:self'],
  'admin': ['read:all', 'update:all', 'delete:all']
};

function checkPermission(user, requiredPermission, resourceId) {
  const userPermissions = permissions[user.role];
  if (!userPermissions.includes(requiredPermission)) {
    return false;
  }
  
  // For self-owned resources, verify ownership
  if (requiredPermission.startsWith('read:self') || 
      requiredPermission.startsWith('update:self')) {
    return user.id === resourceId;
  }
  
  return true;
}

3. Implement Principle of Least Privilege

Grant users only the minimum permissions necessary for their role. Use scoped API keys, granular permissions, and avoid overly broad access patterns.

4. Validate All Inputs

Never trust client-provided identifiers. Always validate that resource IDs, user IDs, and other identifiers correspond to resources the authenticated user is actually permitted to access.

5. Use Secure Defaults

Implement deny-by-default policies where access is denied unless explicitly granted. Avoid creating endpoints that are publicly accessible by default.

6. Regular Security Testing

Integrate automated security scanning into your development workflow. middleBrick's GitHub Action can scan your APIs in CI/CD pipelines, failing builds if new authorization vulnerabilities are detected.

Real-World Impact

Broken access control vulnerabilities have caused some of the most significant data breaches in recent years. In 2019, a major social media platform suffered a breach affecting millions of users due to improper access controls that allowed attackers to view private messages and account information across user boundaries.

The 2017 Equifax breach, while primarily an authentication issue, was exacerbated by broken access controls that allowed attackers to move laterally across systems once initial access was gained. The lack of proper authorization checks meant that compromised credentials could access vast amounts of sensitive data.

According to the OWASP API Security Top 10, broken object level authorization (BOLA) is the #1 API security risk, affecting the majority of APIs tested. BOLA specifically refers to the scenario where APIs expose endpoints that accept user-supplied input (like IDs in URLs) without validating that the user is authorized to access the specified resource.

Real-world CVEs related to broken access control include:

  • CVE-2021-39191: API endpoint allowed access to other users' data by manipulating user ID parameters
  • CVE-2020-15227: Missing authorization checks in administrative endpoints
  • CVE-2019-16240: Privilege escalation through JWT token manipulation

These vulnerabilities often result in regulatory penalties, reputational damage, and costly incident response efforts. The average cost of a data breach reached $4.45 million in 2023, with broken access control being a leading cause of unauthorized data exposure.

Frequently Asked Questions

What's the difference between authentication and authorization?
Authentication verifies who you are (your identity), while authorization determines what you're allowed to do. Authentication answers "Are you who you claim to be?" Authorization answers "What are you allowed to access?" An API can have perfect authentication but still be vulnerable if authorization checks are missing or broken.
How does middleBrick detect broken access control without credentials?
middleBrick uses black-box scanning techniques that modify request parameters to probe for authorization weaknesses. The scanner tests whether APIs properly validate resource ownership by attempting to access data across user boundaries, checking for privilege escalation opportunities, and analyzing response patterns for information disclosure. It doesn't need credentials because it's testing the unauthenticated attack surface.
Can broken access control affect internal APIs?
Yes, internal APIs are often more vulnerable because they're assumed to be 'safe' behind firewalls or within private networks. However, microservices architectures, API gateways, and third-party integrations can all expose internal APIs. Every API endpoint should implement proper authorization regardless of whether it's public or internal.