Bola Idor in Express with Api Keys

Broken Object Level Authorization (BOLA) occurs when an API fails to enforce proper access controls between subjects and objects, allowing one user to act on another user’s resources. In Express.js applications that rely on API keys for authentication, BOLA often arises because keys identify the client application or service account, but the server does not additionally verify that the authenticated subject is authorized to access or modify the specific resource identified in the request (e.g., /users/:userId/profile).

Consider an Express route that retrieves user profile data using an API key for authentication but only checks that a key is valid, not whether the key’s associated client is allowed to view the requested userId:

const express = require('express');
const app = express();

// Middleware that sets req.apiKey from a valid key (simplified)
app.use((req, res, next) => {
  const key = req.headers['x-api-key'];
  if (!key) return res.status(401).json({ error: 'missing api key' });
  // Key validation omitted for brevity
  req.apiKey = key;
  next();
});

// BOLA risk: no check that req.apiKey can access req.params.userId
app.get('/users/:userId/profile', (req, res) => {
  const userProfile = getUserProfileFromDb(req.params.userId);
  res.json(userProfile);
});

An attacker who discovers or guesses another user’s ID can send requests with their own API key, and the server will return data for the target user because the route does not compare the authenticated key’s permissions with the userId in the path. This is a classic BOLA: the API key proves identity of the caller at the application level, but does not enforce object-level authorization on the resource.

BOLA in Express with API keys is common when developers assume API-key authentication alone is sufficient for authorization. Keys often grant broad access to the service or represent a service account, which makes it even more critical to enforce per-request authorization checks. Without these checks, attackers can leverage insecure direct object references to view, modify, or delete other users’ data, leading to data exposure and privacy violations. This pattern is explicitly covered by the OWASP API Security Top 10 (2023) as a Broken Object Level Authorization issue.

Moreover, if the Express app also exposes an OpenAPI/Swagger spec, the spec may describe path parameters but omit runtime authorization constraints. middleBrick’s OpenAPI/Swagger analysis can highlight such missing security schemes or inconsistent scopes, but it does not fix the missing authorization logic in code. Attack patterns like IDOR often map to compliance frameworks such as OWASP API Top 10 and SOC2, underscoring the need to couple API keys with resource-level checks.

To prevent BOLA when using API keys in Express, you must couple authentication (validating the key) with per-request authorization that ensures the key’s subject can access the requested object. Below are concrete, secure patterns you can adopt.

1. Map keys to permissions and subjects

Maintain a lookup that associates each valid API key with the subject (e.g., user ID or client ID) and a set of permissions. Use this mapping in every route that accesses a user-specific resource:

const express = require('express');
const app = express();

// Example key store (in practice, use a secure database or cache)
const keySubjectMap = {
  'key-abc123': { subjectType: 'user', subjectId: 'user-100', permissions: ['read:profile', 'write:profile'] },
  'key-ext456': { subjectType: 'service', subjectId: 'service-batch', permissions: ['read:reports'] }
};

// Authentication + authorization middleware
app.use('/users/:userId', (req, res, next) => {
  const key = req.headers['x-api-key'];
  if (!key) return res.status(401).json({ error: 'missing api key' });
  const principal = keySubjectMap[key];
  if (!principal) return res.status(403).json({ error: 'invalid api key' });
  req.principal = principal;
  next();
});

// Enforce ownership or allowed scopes per route
app.get('/users/:userId/profile', (req, res) => {
  const targetUserId = req.params.userId;
  // BOLA prevention: ensure the authenticated principal can access this user
  if (!req.principal.permissions.includes('read:profile') || req.principal.subjectId !== targetUserId) {
    return res.status(403).json({ error: 'forbidden: insufficient permissions' });
  }
  const userProfile = getUserProfileFromDb(targetUserId);
  res.json(userProfile);
});

This pattern ensures that even with a valid API key, the request is denied unless the key’s subject matches the resource being accessed or the key has explicit permissions for that action.

2. Use scopes and centralized authorization

For service accounts or keys representing integrations, use scopes and a centralized authorization function to avoid duplicating logic:

function canAccessResource(principal, action, resourceType, resourceId) {
  // Implement policy checks, e.g., subject must match resourceId for user data
  if (resourceType === 'user' && principal.subjectType === 'user') {
    return principal.subjectId === resourceId && principal.permissions.includes(action);
  }
  // Allow service keys only for non-user resources
  if (resourceType === 'report' && principal.permissions.includes(action)) {
    return true;
  }
  return false;
}

app.put('/users/:userId/profile', (req, res) => {
  const ok = canAccessResource(req.principal, 'write:profile', 'user', req.params.userId);
  if (!ok) return res.status(403).json({ error: 'forbidden' });
  // proceed with update
  res.json({ message: 'updated' });
});

Additionally, prefer HTTP methods and status codes consistently (e.g., 403 for authorization failures, 404 for non-existent resources to avoid user enumeration), and avoid returning detailed errors that could aid attackers. Regularly rotate keys and audit key usage to reduce the blast radius of compromised credentials.

Tools like middleBrick’s CLI (middlebrick scan <url>) can help detect missing authorization patterns during development, while the GitHub Action can fail builds if security scores drop below your chosen threshold. The MCP Server enables scanning APIs directly from your IDE, supporting rapid feedback as you implement these fixes.