Broken Access Control in Koa with Mongodb

Broken Access Control occurs when authorization checks are missing or incorrectly enforced, allowing attackers to access or modify resources they should not. The combination of Koa and Mongodb can unintentionally expose this vulnerability when application logic relies on route handlers alone to enforce permissions, while database queries do not validate ownership or scope.

In a typical Koa app using Mongodb, a developer might protect an endpoint with middleware that checks for authentication but omits ownership validation at the query layer. For example, an endpoint like /users/:id/profile may verify that a user is logged in but then query Mongodb with only the provided id parameter. If the query does not ensure the requested document belongs to the authenticated subject, an attacker can manipulate the parameter to access another user’s data.

Consider a Koa route that directly uses the id from the request path without scoping the Mongodb filter to the authenticated user:

// Insecure: no ownership check in the database query
app.use(async (ctx) => {
  const userId = ctx.params.id;
  const user = await db.collection('users').findOne({ _id: userId });
  ctx.body = user;
});

An authenticated attacker can change userId to any valid ObjectId and retrieve other users’ profiles. This pattern is common in APIs where access control is implemented only at the application layer and not enforced in the query itself.

Another scenario involves role-based or attribute-based access where Mongodb documents contain sensitive fields (e.g., isAdmin, permissions). If the Koa handler returns the full document without filtering sensitive fields based on the requester’s privileges, data exposure occurs. For instance, a handler might inadvertently expose administrative flags to non-admin users because the query projection is missing or misconfigured.

Additionally, APIs that accept filter parameters directly from the client can suffer if those parameters are merged into a Mongodb query without strict allow-listing. An attacker could inject keys like { role: 'admin' } into a filter payload to escalate privileges or bypass intended restrictions. This aligns with BOLA/IDOR patterns where Insecure Direct Object References enable horizontal or vertical privilege escalation.

To summarize, the vulnerability arises when Koa route handlers trust client-supplied identifiers without enforcing scoped queries in Mongodb, when sensitive fields are not projected carefully, and when filters are constructed from unchecked input. These gaps allow attackers to bypass intended access boundaries even when basic authentication is in place.

Remediation focuses on ensuring every database query enforces ownership or role constraints and that sensitive data is never over-disclosed. The following patterns demonstrate secure practices for Koa with Mongodb.

1. Scope queries to the authenticated subject

Always include the authenticated user’s identifier in the query filter. This ensures users can only access their own documents regardless of the ID supplied in the request.

// Secure: scope query to authenticated user
app.use(async (ctx) => {
  const authenticatedUserId = ctx.state.user._id; // from auth middleware
  const userId = ctx.params.id;

  // Enforce that the requested ID matches the authenticated user
  if (userId !== authenticatedUserId) {
    ctx.status = 403;
    ctx.body = { error: 'Forbidden' };
    return;
  }

  const user = await db.collection('users').findOne({ _id: userId });
  ctx.body = user;
});

2. Use database-level projection to limit returned fields

Apply field-level filtering in the query to prevent exposure of sensitive attributes such as passwords or admin flags.

// Secure: restrict returned fields
const user = await db.collection('users').findOne(
  { _id: authenticatedUserId },
  { projection: { email: 1, profile: 1, _id: 1 } } // exclude password, isAdmin, tokens
);
ctx.body = user;

3. Validate and sanitize input before building queries

Avoid merging raw client input into query objects. Use allow-listing and type validation to prevent injection-like manipulation.

// Secure: validate and construct query safely
const allowedKeys = new Set(['name', 'email']);
const filter = {};
for (const [key, value] of Object.entries(req.query)) {
  if (allowedKeys.has(key)) {
    filter[key] = value;
  }
}
filter.userId = authenticatedUserId; // enforce ownership
const results = await db.collection('items').find(filter).toArray();
ctx.body = results;

4. Implement robust middleware for authorization checks

Centralize authorization logic so that handlers do not need to repeat ownership or role checks.

// auth middleware example
const authorizeOwnResource = async (ctx, next) => {
  const resourceId = ctx.params.id;
  const resource = await db.collection('resources').findOne({ _id: resourceId });
  if (!resource || resource.userId !== ctx.state.user._id) {
    ctx.status = 403;
    ctx.body = { error: 'Access denied' };
    return;
  }
  await next();
};

app.use('/resources/:id', authorizeOwnResource, async (ctx) => {
  ctx.body = await db.collection('resources').findOne({ _id: ctx.params.id });
});

5. Apply principle of least privilege to database roles

Configure the Mongodb connection used by Koa with a dedicated user that has only the necessary read/write permissions for the required collections. Avoid using a highly privileged account for routine operations.