Broken Access Control in Koa with Bearer Tokens

Broken Access Control in a Koa application using Bearer Tokens typically arises when authorization checks are incomplete or bypassed after authentication. Authentication verifies identity (e.g., a valid Bearer Token), but authorization determines what an authenticated identity is allowed to do. If routes or middleware fail to enforce role-based or ownership-based checks, an attacker can access or modify resources they should not.

In Koa, a common pattern is to authenticate a request by verifying a Bearer Token and attaching a user payload to ctx.state. However, if subsequent route handlers do not validate that the authenticated user is authorized for the specific resource, BOLA (Broken Level Authorization) / IDOR vulnerabilities occur. For example, an API endpoint like /api/users/:id might verify a token but then directly use ctx.params.id to fetch user data without checking whether the authenticated user owns that ID. An attacker can simply change the numeric ID in the URL to access other users' data, which maps to the OWASP API Top 10 category for Broken Object Level Authorization.

Consider a Koa route that reads a user profile without ownership validation:

// Insecure example: missing ownership check
router.get('/api/users/:id', async (ctx) => {
  const user = await db.users.findByPk(ctx.params.id);
  if (!user) {
    ctx.status = 404;
    return;
  }
  ctx.body = user;
});

Even if authentication placed the requester’s identity in ctx.state.user, the handler ignores it. An authenticated user with a valid Bearer Token can enumerate or access any user record by incrementing IDs, demonstrating BOLA/IDOR. A similar issue arises in endpoints that should enforce role-based access control (RBAC) but do not inspect roles or scopes embedded in the token. For instance, an endpoint that should be restricted to administrators might only check for the presence of a token and not validate a role claim such as ctx.state.user.role. This is an example of insufficient authorization checks, another facet of Broken Access Control.

SSRF and related server-side request forgery risks can also intersect with access control when backend requests are made using elevated or static credentials, but the primary concern with Bearer Tokens in Koa is ensuring every handler validates both authentication and fine-grained authorization. The scanner checks listed in the product description — Authentication, BOLA/IDOR, BFLA/Privilege Escalation, and Property Authorization — are designed to detect these classes of flaws by correlating runtime behavior with OpenAPI/Swagger specifications and their $ref definitions.

Remediation focuses on consistently validating both the Bearer Token and the authorization context for each request. In Koa, this is typically implemented with centralized middleware that attaches user and permission data to ctx.state and then checks those values in routes or additional middleware before performing sensitive operations.

First, ensure token verification and user enrichment occur early in the middleware stack. Use a robust JWT library to verify the token and fetch user data, then store minimal claims on ctx.state for downstream use:

// Secure middleware pattern for Bearer Token authentication
const jwt = require('jsonwebtoken');

async function authMiddleware(ctx, next) {
  const authHeader = ctx.get('Authorization');
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    ctx.status = 401;
    ctx.body = { error: 'Unauthorized' };
    return;
  }
  const token = authHeader.split(' ')[1];
  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    ctx.state.user = {
      id: decoded.sub,
      role: decoded.role,
      scopes: decoded.scopes || []
    };
  } catch (err) {
    ctx.status = 401;
    ctx.body = { error: 'Invalid token' };
    return;
  }
  await next();
}

After authentication, enforce authorization in each route or via a dedicated authorization helper. For example, when a route includes an :id parameter, compare it to the authenticated user’s ID, or check role/scopes for administrative actions:

// Secure route with ownership and role checks
router.get('/api/users/:id', async (ctx) =>
  {
  const requester = ctx.state.user;
  const targetId = parseInt(ctx.params.id, 10);
  // Ownership check for user-specific endpoints
  if (requester.id !== targetId && !requester.scopes.includes('admin:read')) {
    ctx.status = 403;
    ctx.body = { error: 'Forbidden' };
    return;
  }
  const user = await db.users.findByPk(targetId);
  if (!user) {
    ctx.status = 404;
    return;
  }
  ctx.body = user;
});

For endpoints that act on other resources (e.g., posts, invoices), implement a policy check that validates the requesting user’s relationship to that resource. Do not rely solely on role claims; prefer explicit checks that tie the resource to the user, such as checking a userId foreign key or using a permission service. Additionally, ensure that tokens are transmitted only over HTTPS and that scopes and roles issued to the token are minimal and scoped to the least privilege required. The middleBrick CLI can be used to scan from terminal with middlebrick scan <url> to validate these controls, while the Pro plan enables continuous monitoring and CI/CD integration to catch regressions before deployment.