Rate Limiting Bypass in Adonisjs with Mutual Tls

Rate limiting in Adonisjs typically relies on identifying clients by IP address or authenticated user ID. When mutual TLS (mTLS) is enforced, the server validates client certificates, but if rate limiting is applied only after the TLS handshake—or if the limiting logic does not account for the mTLS context—an attacker can bypass intended limits by cycling through valid client certificates. Each certificate may present a different client identity to the application, causing the rate limiter to associate requests with distinct identifiers and reset counters unintentionally.

In practice, this can occur when middleware ordering places rate limiting before mTLS verification or when the rate limiter key does not incorporate certificate attributes (e.g., the Common Name or a SAN). An attacker with access to a pool of valid client certificates can send requests that appear to originate from different clients, evading rate thresholds defined per certificate or per identity. This is a form of identity confusion where the trust boundary (mTLS) and the enforcement boundary (rate limiting) are misaligned.

For example, consider an Adonisjs application using a custom rate limiter based on IP address while requiring client certificates for certain routes. If the rate limiter key is solely the remote IP, rotating certificates from the same IP does not affect the limiting bucket. Conversely, if the key includes the client certificate fingerprint but the middleware is configured to skip limiting for authenticated TLS clients, the protection is effectively disabled for those endpoints. Such misconfiguration allows unauthenticated-style flooding via authenticated channels, violating the intended request caps.

The interaction also exposes risks where certificate validation is performed but not consistently applied across routes. An attacker might target endpoints that lack strict mTLS enforcement while sharing the same rate limiting configuration, using valid certificates on protected routes to infer timing or behavior on unprotected ones. The vulnerability is not in mTLS itself but in how rate limiting integrates with the certificate context, particularly when spec parsing (for OpenAPI) does not reflect runtime enforcement gaps.

To detect this class of issue, scans examine whether rate limiting checks occur before or after mTLS validation in the request lifecycle and whether the rate limiter key includes certificate-derived identifiers. Findings highlight mismatches between identity verification and request counting, emphasizing the need to bind rate limits to the same attributes used for mutual authentication.

Remediation centers on ensuring that rate limiting operates with full awareness of the mTLS identity and that enforcement is consistent across all relevant endpoints. In Adonisjs, this means tying rate limiter keys to certificate attributes and validating that middleware ordering and conditions align with security policy.

First, include the client certificate fingerprint or subject in the rate limiting key. When mTLS is enforced, extract relevant fields from the verified certificate and use them as part of the identifier. Below is an example of configuring a rate limiter that incorporates the certificate fingerprint in Adonisjs using the @adonisjs/ratelimit package and hooking into the request lifecycle to read the certificate from the connection.

import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import { Exception } from '@poppinss/utils'

export default class RateLimitProvider {
  public async handle(ctx: HttpContextContract) {
    const tls = ctx.request.tls
    // Assume client cert is exposed as tls.clientCert
    const fingerprint = tls.clientCert?.fingerprint || 'unknown'
    const key = `ratelimit:mTLS:${fingerprint}`

    // Use a custom rate limiter store or adapter that respects this key
    await this.rateLimiter.check(key, 10, 60) // 10 requests per 60 seconds
  }
}

import Route from '@ioc:Adonis/Core/Route'

Route.group(() => {
  Route.get('/secure', async ({ request }) => {
    // request.tls should already be validated
    return { status: 'ok' }
  }).middleware(['verifyMtls', 'rateLimitWithCert'])
}).prefix('api')