CWE-284 in APIs

CWE-284: Improper Access Control is a critical software weakness where an application fails to properly verify that a user has the correct permissions to access a resource, function, or data. According to the MITRE Common Weakness Enumeration, this weakness occurs when "the software does not enforce or incorrectly enforces access control measures."

This fundamental flaw allows unauthorized users to access restricted functionality, view sensitive data, or perform actions they should not be permitted to execute. The weakness can manifest at multiple levels: object-level access, function-level access, or data-level access. When exploited, it can lead to data breaches, privilege escalation, and complete system compromise.

The impact of CWE-284 varies based on what the attacker gains access to. In the worst cases, attackers can access administrative functions, modify critical data, or escalate their privileges to gain complete control over the system. This weakness is particularly dangerous because it often provides attackers with a foothold to exploit other vulnerabilities or extract sensitive information without triggering traditional security alerts.

APIs are particularly vulnerable to CWE-284 due to their stateless nature and the complexity of modern authentication and authorization systems. In API contexts, this weakness often manifests as missing or incorrect authorization checks after authentication has succeeded. The classic pattern: "user is authenticated, therefore user is authorized" leads to dangerous assumptions.

Common API manifestations include:

• Missing Authorization Headers: APIs that rely solely on authentication tokens without validating user permissions for specific operations
• Inconsistent Access Control: Different endpoints applying authorization checks inconsistently, creating security gaps
• Parameter Manipulation: APIs that trust client-supplied identifiers without verifying ownership or access rights
• Role-Based Access Control (RBAC) Failures: Incorrectly configured roles or permissions that grant excessive access
• Resource-Based Access Control (ReBAC) Gaps: APIs that don't verify whether a user can access specific resources based on relationships

Consider a banking API where a user requests account details: GET /accounts/12345. If the API only checks that the user is authenticated but doesn't verify that the user owns account 12345, an attacker who obtains any valid token can access any account. This is the essence of Insecure Direct Object References (IDOR), a common manifestation of CWE-284 in APIs.

Detecting CWE-284 requires systematic testing of authorization mechanisms across all API endpoints. Manual testing involves attempting to access resources with different user roles, modifying identifiers in requests, and verifying that access is properly restricted. However, manual testing is time-consuming and often incomplete.

Automated detection through security scanning provides comprehensive coverage. middleBrick's BOLA/IDOR scanning module specifically targets CWE-284 by testing unauthenticated access to authenticated endpoints and verifying proper authorization controls. The scanner attempts to access protected resources without valid credentials and checks if sensitive data is exposed.

For example, middleBrick tests patterns like:

// Testing for missing authorization checksGET /api/users/123/profile - without authenticationGET /api/admin/settings - as regular userPOST /api/orders/999/cancel - with insufficient permissions

The scanner also analyzes OpenAPI specifications to identify endpoints that should require authentication but lack proper security definitions. When specifications show security: [] or missing authentication requirements, middleBrick flags these as potential CWE-284 vulnerabilities.

Additional detection techniques include:

• Role Mining: Testing each endpoint with different user roles to identify privilege escalation paths
• Parameter Fuzzing: Modifying user IDs, resource IDs, and other identifiers to test access controls
• Business Logic Analysis: Verifying that API operations respect business rules and user relationships
• Cross-User Data Access: Attempting to access data belonging to other users

middleBrick's continuous monitoring in Pro tier automatically re-tests APIs on configurable schedules, ensuring that newly introduced endpoints or changed authorization logic don't reintroduce CWE-284 vulnerabilities.

Fixing CWE-284 requires implementing defense-in-depth authorization controls throughout the API. The fundamental principle: never trust the client, always verify on the server. Here's how to remediate this weakness:

Implement Proper Authorization Checks

Every endpoint that accesses sensitive data or performs privileged operations must verify user permissions. Use middleware or decorators to centralize authorization logic:

const authorize = (requiredPermission) => {
  return (req, res, next) => {
    if (!req.user || !req.user.permissions.includes(requiredPermission)) {
      return res.status(403).json({ error: 'Insufficient permissions' });
    }
    next();
  };
};

// Apply authorization to protected endpoints
app.get('/api/admin/settings', authorize('admin.access'), (req, res) => {
  res.json({ settings: getAdminSettings() });

Verify Resource Ownership

Always validate that the authenticated user has rights to access specific resources:

// Never trust client-supplied IDs
app.get('/api/accounts/:accountId', async (req, res) => {
  const accountId = req.params.accountId;
  const userId = req.user.id;
  
  // Verify ownership before accessing data
  const account = await Account.findOne({ 
    where: { id: accountId, userId: userId }
  });
  
  if (!account) {
    return res.status(404).json({ error: 'Account not found or access denied' });
  }
  
  res.json(account);

Implement Principle of Least Privilege

Grant users only the minimum permissions necessary for their role. Avoid overly broad permissions that can be exploited:

// Granular permissions instead of broad roles
const permissions = [
  'user.read',        // View own profile
  'user.update',      // Update own profile
  'account.read',     // View accounts
  'account.write',    // Create/modify accounts
  'admin.access'      // Administrative functions
// Check specific permissions rather than roles
if (req.user.permissions.includes('account.read')) {
  // Allow access

Validate Input Parameters

Never trust client-supplied identifiers. Always validate that requested resources exist and that the user has access rights:

app.delete('/api/orders/:orderId', async (req, res) => {
  const orderId = req.params.orderId;
  const userId = req.user.id;
  
  // Verify order exists and belongs to user
  const order = await Order.findOne({ 
    where: { id: orderId, userId: userId }
  });
  
  if (!order) {
    return res.status(404).json({ error: 'Order not found or access denied' });
  }
  
  // Proceed with deletion

Audit and Monitor

Implement logging for authorization failures and monitor for suspicious patterns. middleBrick's Pro tier provides continuous monitoring with alerts when authorization controls are bypassed or when new vulnerabilities are detected.

By systematically applying these remediation strategies and using automated scanning tools like middleBrick to verify fixes, developers can eliminate CWE-284 vulnerabilities and ensure robust access control throughout their APIs.