Broken Access Control in Adonisjs with Mutual Tls

Broken Access Control occurs when an API fails to enforce proper authorization checks, allowing one user to access or modify another user’s resources. In AdonisJS, this commonly maps to the BOLA/IDOR category in the OWASP API Top 10. Even when you terminate TLS with Mutual TLS (mTLS), transport-layer authentication does not automatically imply application-level authorization. mTLS ensures the client possesses a valid certificate, but it does not enforce role-based or ownership-based checks inside your controllers or routes. If route handlers in AdonisJS skip policy or permission checks and rely only on the presence of a client certificate, an attacker who obtains or guesses another user’s certificate can directly manipulate resource identifiers (e.g., /files/:id) and access or modify data they should not see.

For example, consider an AdonisJS route that retrieves a document by ID without verifying that the authenticated (mTLS) user owns that document:

// routes.ts
Route.get('/documents/:id', async ({ params, request }) => {
  const doc = await Document.findOrFail(params.id)
  return doc
})

Here, the client presents a certificate that mTLS validates, but the handler does not compare the authenticated user’s ID (extracted from the certificate subject or an mTLS-derived user record) with the document’s user_id. This is a classic BOLA flaw: Level-Based Access Control is effectively missing, and the application trusts the route parameter alone. An attacker can increment or guess IDs and enumerate sensitive data without triggering an authorization failure.

Additionally, mTLS is often implemented at the load balancer or reverse proxy, and the application may receive the client certificate via headers (e.g., SSL_CLIENT_CERT or a custom header). If AdonisJS uses these headers to derive the user but does not re-validate authorization on every request, and if the route logic does not scope queries to the authenticated subject, the unauthenticated attack surface includes enumeration and tampering. This becomes more impactful when endpoints expose list or export operations without row-level filters, enabling broader data exposure beyond the intended IDOR scenario.

Another subtle risk arises when development or staging environments disable certain policies for convenience. If mTLS is enforced in production but authorization checks are accidentally omitted in route groups or middleware stacks, the production surface remains vulnerable despite the presence of mTLS. Therefore, mTLS should be treated as transport authentication, not a replacement for robust application-level authorization and ownership verification.

To address Broken Access Control when using Mutual TLS in AdonisJS, treat mTLS as the identity source and enforce explicit authorization on every request. Always scope data access to the authenticated principal derived from the client certificate, and apply policies to verify ownership or role permissions.

First, extract user identity from the mTLS certificate in a provider or middleware. A common pattern is to read the certificate subject and map it to a local user record:

// start/hooks.ts or a custom provider
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import User from 'App/Models/User'

export const getUserFromMtlsCertificate = async (ctx: HttpContextContract) => {
  const certHeader = ctx.request.header('x-ssl-client-cert')
  if (!certHeader) {
    return null
  }
  // Simplified: parse the PEM and extract CN or a SAN email
  // Use a robust library in production (e.g., node-forge or pem) to avoid regex pitfalls
  const match = certHeader.match(/CN=([^,]+)/)
  const commonName = match ? match[1] : null
  if (!commonName) {
    return null
  }
  const user = await User.findBy('email', commonName)
  return user
}

Second, create an authentication guard that sets the user when a valid certificate is present, and ensure unauthorized requests are rejected early:

// start/hooks.ts or a provider
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import User from 'App/Models/User'
import { exception } from '@poppinss/utils'

export const authenticateWithMtls = async (ctx: HttpContextContract) => {
  const user = await getUserFromMtlsCertificate(ctx)
  if (!user) {
    throw exception.unauthorized('Invalid or missing client certificate')
  }
  ctx.auth.user = user
  ctx.auth.type = 'mtls'
}

Third, enforce ownership checks in route handlers or apply global policies. For example, scope document queries to the authenticated user:

// routes.ts
Route.get('/documents/:id', async ({ auth, params }) => {
  const document = await Document.query()
    .where('id', params.id)
    .where('user_id', auth.user?.id)
    .firstOrFail()
  return document
})

Finally, in the Pro plan, you can leverage continuous monitoring to detect deviations such as missing authorization checks on endpoints that present mTLS credentials. The GitHub Action can fail a build if risk scores exceed your threshold, ensuring that new routes or changes do not reintroduce BOLA/IDOR issues. For local development and CI, the MCP Server allows you to scan APIs directly from your IDE, providing rapid feedback on authorization gaps while you code.