Privilege Escalation in Adonisjs with Mutual Tls

AdonisJS is a Node.js web framework that often relies on session-based or token-based authentication. When Mutual TLS (mTLS) is introduced as an additional or alternative authentication mechanism, it can inadvertently enable privilege escalation if role or scope information is derived from the client certificate without strict validation. In an mTLS flow, the server requests a client certificate and verifies it against a trusted Certificate Authority (CA). If the application then maps certificate attributes—such as the subject distinguished name (DN), organizational unit (OU), or custom extensions—directly to user roles or permissions without corroborating those claims against a server-side authorization model, an attacker who can present a valid but low-privilege certificate may be granted elevated permissions.

For example, consider an AdonisJS route that relies on an mTLS client certificate to identify a service account. If the route reads request.socket.getPeerCertificate() and uses fields like OU to assign an admin role, a compromised or misissued certificate with OU=Admin would allow horizontal or vertical privilege escalation. This becomes critical when the server does not enforce additional authorization checks (such as Ability-based rules or policy checks) after mTLS authentication. The authentication step confirms identity, but without explicit authorization, the identity’s privileges may be unintentionally broad.

Moreover, in environments where mTLS is used alongside other mechanisms (e.g., session cookies or API keys), misconfiguration can lead to bypass scenarios. An attacker might exploit inconsistent enforcement—such as allowing unauthenticated routes to fallback to certificate-derived identity—to escalate privileges. The risk is amplified when certificate verification is partial (e.g., only verifying the certificate exists but not its constraints, such as Key Usage or Extended Key Usage). AdonisJS applications must treat mTLS as one factor in a broader authorization strategy, validating certificate metadata against a strict access control model to mitigate privilege escalation.

To secure AdonisJS applications using Mutual TLS, implement strict validation of client certificates and enforce authorization independent of authentication. Avoid directly mapping certificate fields to roles. Instead, treat the certificate as an identity signal and apply server-side authorization rules. Below are concrete code examples demonstrating secure mTLS setup and authorization in AdonisJS.

1. Configure mTLS in the AdonisJS server (HTTPS server)

Ensure the server requests and validates client certificates. Use the https module with requestCert and rejectUnauthorized set appropriately. In AdonisJS, you typically configure the HTTPS server in start/server.ts or via the application provider.

import { Server } from '@adonisjs/core';
import https from 'https';
import fs from 'fs';

export default class ServerProvider {
  public async register() {
    // This example assumes you are customizing server creation; AdonisJS v5+ uses ace hooks
  }
}

// Example: Custom HTTPS server creation (e.g., in a custom provider or script)
const server = https.createServer({
  key: fs.readFileSync('path/to/server-key.pem'),
  cert: fs.readFileSync('path/to/server-cert.pem'),
  ca: fs.readFileSync('path/to/ca-bundle.pem'),
  requestCert: true,
  rejectUnauthorized: true, // Critical: enforce client certificate validation
}, (req, res) => {
  // Handle request
});

server.listen(443);

2. Validate certificate fields and map to internal identity

After mTLS authentication, inspect the client certificate and validate it against policy. Do not trust the certificate’s OU or CN for authorization. Instead, map to a known user or service in your database and enforce permissions via an authorization layer.

import { HttpContextContract } from '@adonisjs/core/http';

export default class AuthController {
  public async verifyMtlsCert({ request }: HttpContextContract) {
    const cert = request.socket.getPeerCertificate();
    if (!cert || Object.keys(cert).length === 0) {
      throw new Error('Client certificate required');
    }

    // Validate certificate constraints (example checks)
    if (cert.valid_to && new Date(cert.valid_to) < new Date()) {
      throw new Error('Client certificate expired');
    }

    // Example: Extract a custom extension (e.g., 1.3.6.1.4.1.56836.1.1) for service ID
    const ext = cert.extensions?.find(e => e.name === '1.3.6.1.4.1.56836.1.1');
    const serviceId = ext?.value;

    if (!serviceId) {
      throw new Error('Missing required certificate extension');
    }

    // Map serviceId to a role via server-side data, not certificate metadata
    const service = await Database.from('services').where({ service_id: serviceId }).first();
    if (!service) {
      throw new Error('Service not authorized');
    }

    // Attach a verified identity to the request context
    request.authService = { id: service.id, role: service.role };
  }
}

3. Enforce authorization after authentication

Use an Ability-based or policy system to authorize actions. Even after mTLS authentication, verify that the authenticated identity is permitted to perform the requested action.

import { Ability, createMongoAbility } from '@casl/ability';
import { HttpContextContract } from '@adonisjs/core/http';

// Define abilities based on the verified role from the certificate mapping
const ability = createMongoAbility([
  { action: 'read', subject: 'reports' },
  { action: 'manage', subject: 'admin', conditions: { role: 'admin' } },
]);

export default class ReportController {
  public async index({ request }: HttpContextContract) {
    const service = request.authService;
    if (!ability.can('read', 'reports')) {
      throw new Error('Unauthorized: insufficient privileges');
    }
    // Proceed with safe, authorized logic
    return Report.all();
  }
}