Cors Wildcard in Adonisjs with Mutual Tls

When an AdonisJS application uses a wildcard CORS policy (*) while also enforcing Mutual TLS (mTLS), the combination can unintentionally broaden the attack surface despite the presence of strong client authentication. CORS is a browser-enforced mechanism; it does not restrict server-to-server requests. mTLS ensures that only clients possessing a valid certificate trusted by the server can establish a TLS connection. However, if the server’s CORS configuration includes Access-Control-Allow-Origin: * and allows credentials (e.g., cookies or client-side certificates), the effective origin may become unpredictable in certain deployments, especially when intermediary proxies or load balancers terminate TLS and forward requests to the application over HTTP.

In this setup, the server validates the client certificate (mTLS), but then applies a permissive CORS rule. An attacker who can cause a victim’s browser to make a cross-origin request (e.g., via a malicious page) will have the browser present the stored cookies or client certificate (if accessible). Because CORS allows any origin, the response may be readable by the attacker’s JavaScript if the response headers permit it, leading to unauthorized data exposure. This is particularly relevant for endpoints that return sensitive profile or session information and rely on cookies for session continuity alongside mTLS for client identification.

Moreover, if the AdonisJS app uses route-based CORS policies and the wildcard is applied at a higher level (e.g., globally or to a group of routes), developers may mistakenly assume that mTLS alone prevents unauthorized access. In reality, CORS and mTLS protect different layers: mTLS authenticates the peer, while CORS governs which origins can read responses in a browser context. A wildcard CORS policy can nullify the principle of least privilege by allowing any web page to interact with authenticated endpoints, increasing the risk of CSRF-like scenarios where credentials and client certificates are automatically included by the browser.

For compliance mappings, findings from this misconfiguration may align with OWASP API Security Top 10 controls such as Broken Object Level Authorization (BOLA) when combined with IDOR risks, and improper CORS configuration under the CORS and Cache-Control category. Because mTLS ensures only authorized clients connect, the danger lies in the overly permissive CORS rule that enables unauthorized web origins to access responses. middleBrick scans detect such combinations during unauthenticated black-box testing, flagging the presence of a wildcard Access-Control-Allow-Origin alongside mTLS-enabled endpoints and providing prioritized remediation guidance.

To securely handle Mutual TLS in AdonisJS, you should explicitly define allowed origins and avoid wildcard CORS entries when client certificates are used. Instead of *, specify exact origins or implement a dynamic origin resolver that echoes the Origin header only when the client certificate is valid and the origin is trusted.

Below is a concrete example of configuring CORS with mTLS in AdonisJS using the built-in @adonisjs/cors package. This configuration ensures that only selected origins are permitted and that credentials are not exposed to untrusted domains.

// start/cors.ts
import { cors } from '@ioc:Adonis/Addons/Cors'

export default cors({
  enabled: true,
  origin: [
    'https://app.yourdomain.com',
    'https://admin.yourdomain.com',
  ],
  allowCredentials: true,
  allowHeaders: [
    'authorization',
    'content-type',
    'x-client-cert-fingerprint',
  ],
  allowMethods: [
    'GET',
    'POST',
    'PUT',
    'DELETE',
    'PATCH',
  ],
  maxAge: 86400,
})

In environments where you rely on mTLS, you can also inspect the client certificate within the request lifecycle to make dynamic decisions. AdonisJS allows you to hook into the request context to validate the certificate fingerprint against a known list or to enforce additional authorization checks before processing the request.

// start/hooks.ts
import { defineConfig } from 'acepit'
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'

export const hooks = defineConfig({
  async preAuthentication({ request }: { request: HttpContextContract }) {
    const cert = request.getRawRequest().socket.getPeerCertificate?.()
    if (!cert || !cert.fingerprint) {
      throw new Error('Client certificate required')
    }
    const allowedFingerprints = new Set([
      'AA:BB:CC:DD:EE:FF:...',
    ])
    if (!allowedFingerprints.has(cert.fingerprint)) {
      throw new Error('Certificate not authorized')
    }
    request.authClientCertificate = cert
  },
})

Additionally, ensure that your web server or reverse proxy (e.g., Nginx, Traefik) is configured to pass the client certificate information to the application securely, and that TLS termination happens only after successful client certificate validation. Never set Access-Control-Allow-Origin to * when allowCredentials is true, as this combination is disallowed by browsers and can lead to inconsistent behavior or security weaknesses.

For teams using the middleBrick platform, the Pro plan’s continuous monitoring can be configured to alert when a wildcard CORS origin is detected on endpoints that require strong client authentication, helping maintain a secure posture without relying on manual audits.