Api Rate Abuse in Nestjs with Mutual Tls

Rate abuse in an API stack using Mutual TLS (mTLS) with NestJS involves two axes: the NestJS application layer and the transport layer enforced by mTLS. Even when mTLS ensures that only clients with a valid client certificate can initiate a TLS handshake, the application itself must still enforce usage limits. Without application-level controls, an authenticated mTLS client can issue many requests per second, exhausting server resources, causing denial of service, or enabling brute-force or enumeration attacks on sensitive endpoints.

In NestJS, developers commonly use guards, interceptors, or custom decorators to enforce authorization and authentication. However, mTLS typically terminates at the reverse proxy or load balancer (or at the Node TLS layer), and the framework may only see that a valid client certificate was presented. If rate limiting is implemented naively—such as counting requests by IP or by a parsed certificate field without considering distributed clients or shared certificates—attackers can bypass limits by rotating client certificates or using many valid certificates within the same rate bucket.

A concrete scenario: an endpoint that lists user details might be protected by mTLS so that only corporate-issued clients can connect. Without per-identity rate limiting, a malicious holder of a valid certificate can iterate over user IDs and scrape data. Additionally, if the NestJS app does not validate the certificate’s metadata (e.g., serial number or distinguished name) against an authorization store on each request, revoked or suspicious certificates can still generate high request volumes until detection occurs. This is an example of BOLA/IDOR when combined with weak rate controls, because the primary identifier used for authorization (the certificate) is not coupled with fine-grained policy checks at the handler level.

Moreover, mTLS setups sometimes use a shared corporate CA, meaning many clients share the same trust chain. If rate limiting is applied at the proxy using the TLS session or certificate fingerprint, an attacker with one valid certificate can still saturate backend services. The NestJS application must therefore implement a second factor—such as an API key, user ID from the certificate’s extended key usage, or a JWT mapped to the certificate—to enforce per-subject limits. Otherwise, the 5–15 second scan window used by tools like middleBrick may flag the endpoint as vulnerable to BOLA/IDOR and excessive agency when LLM endpoints are also exposed without per-client throttling.

Instrumentation matters: logging the certificate’s subject and serial number on each request enables monitoring, but does not itself enforce limits. Middleware that reads the client certificate from the request and maps it to a rate-limiting key (e.g., a Redis sorted set keyed by cert serial) is necessary. Without this, the application may incorrectly assume mTLS alone provides abuse prevention. Findings from a middleBrick scan in this configuration often highlight missing rate limiting on authenticated paths and improper authorization checks, which map to OWASP API Top 10:2023 A07:2021 (Identification and Authentication Failures) and A05:2023 (Security Misconfiguration).

To remediate rate abuse in NestJS with mTLS, combine transport-layer identity extraction with application-level rate limiting tied to a verifiable subject. Below are concrete, syntactically correct examples that show how to read client certificate details and enforce per-identity limits.

import { Injectable, NestMiddleware } from '@nestjs/common';
import { Request, Response, NextFunction } from 'express';

@Injectable()
export class MtlsRateLimitMiddleware implements NestMiddleware {
  // Simple in-memory store for demonstration; use Redis in production
  private readonly limits = new Map();
  private readonly windowMs = 60_000; // 1 minute
  private readonly maxRequests = 30;

  use(req: Request, res: Response, next: NextFunction): void {
    // Express sets req.socket when client certificate is verified by the proxy or Node TLS
    const socket = (req as any).socket as { getPeerCertificate?: () => any };
    const cert = socket?.getPeerCertificate?.();
    if (!cert || Object.keys(cert).length === 0) {
      res.status(400).send('mTLS certificate required');
      return;
    }
    // Use certificate serial or a mapped subject; ensure it's stable and non-PII
    const subject = cert.subject || JSON.stringify(cert);
    const key = cert.serialNumber || subject;
    const now = Date.now();
    const record = this.limits.get(key) || { count: 0, lastReset: now };

    if (now - record.lastReset > this.windowMs) {
      record.count = 0;
      record.lastReset = now;
    }
    record.count += 1;
    this.limits.set(key, record);

    if (record.count > this.maxRequests) {
      res.status(429).send('Rate limit exceeded');
      return;
    }
    next();
  }
}

Register the middleware in your NestJS module and apply it to routes that require protection:

import { MiddlewareConsumer, Module, NestModule } from '@nestjs/common';
import { MtlsRateLimitMiddleware } from './mtls-rate-limit.middleware';

@Module({})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer
      .apply(MtlsRateLimitMiddleware)
      .forRoutes('users/:id', 'transactions', 'llm/completions'); // sensitive endpoints
  }
}

For stronger identity-based limits, extract a stable user identifier from the certificate, such as an email in Extended Key Usage or a mapping stored server-side:

import { Injectable } from '@nastjs/common';

@Injectable()
export class CertMappingService {
  // Example mapping; in production use a database with revocation checks
  private certToUser = new Map();

  mapCertToUser(cert: any): string | null {
    const sn = cert.serialNumber;
    return this.certToUser.get(sn) || null;
  }

  registerCert(cert: any, userId: string): void {
    this.certToUser.set(cert.serialNumber, userId);
  }
}

Use this mapping inside your rate-limiter to enforce per-user limits rather than per-certificate, reducing the impact of shared CA scenarios. Combine this with global rate limiting at the gateway to defend against volumetric attacks even when client certificates are valid.

Finally, ensure your NestJS app validates certificate revocation via OCSP or CRL checks at the proxy or TLS layer; the application should reject requests with revoked mTLS credentials. These steps align with middleBrick’s findings on BOLA/IDOR and rate limiting, and they help meet compliance mappings to OWASP API Top 10 and SOC2 controls.