Api Rate Abuse in Nestjs with Bearer Tokens

Rate abuse in a NestJS API that uses Bearer tokens arises when an attacker can make an excessive number of requests either before tokens are validated or after validation without adequate per-identity throttling. Even when tokens are verified correctly, the application may lack request-rate limits at multiple layers (global, per-route, and per-identity), allowing a single client to flood endpoints, exhaust server resources, and degrade availability.

NestJS does not enforce rate limiting by default. If you add a global guard or an interceptor that validates Bearer tokens but do not also enforce a rate policy, an unauthenticated attacker can still probe authentication boundaries and a valid token holder can exceed acceptable usage. Common patterns that expose risk include:

• Placing rate-limiting logic only after authentication, which still permits a burst of authenticated abuse using a stolen or compromised token.
• Using a single global limit without considering per-user or per-API-key dimensions, enabling token sharing among multiple users and masking abusive behavior.
• Relying solely on IP-based limits when tokens are used, which breaks down in shared environments (e.g., NAT gateways or API gateways) and in mobile scenarios where IPs change infrequently but token misuse persists.

Attackers exploit these gaps in several ways. They may automate credential stuffing with a token that was leaked or obtained via insecure storage, or they may attempt to exhaust rate budgets to trigger denial-of-service conditions for legitimate users. In systems where tokens carry user identity (e.g., a sub claim), abuse can be targeted at specific accounts, creating customer-impacting scenarios that appear as volumetric spikes in logs. Because Bearer tokens are typically passed in the Authorization header, rate-limiting strategies must inspect that header to scope limits to the token or the user it represents, rather than only the client IP.

Without per-token or per-user limits, you also lose visibility into usage anomalies that would otherwise surface in monitoring. For example, a token used at an unusually high QPS or at odd hours may indicate token exfiltration or automated scraping, but such signals are only observable when requests are tracked by identity. Even if your authentication layer validates token signatures and scopes, missing rate controls leave a gap in the attack surface that can be leveraged for disruption or as a precursor to more focused attacks like injection or IDOR.

Architecturally, the exposure often stems from inconsistent layering: authentication guards validate tokens, but dedicated rate-limiting mechanisms are either absent or applied too broadly. In distributed deployments, shared state for counters may be missing or misconfigured, causing limits to be ineffective across instances. These issues are not specific to NestJS but are commonly realized in NestJS applications because developers assume that token validation alone constrains misuse, which is not sufficient without explicit rate policies tied to the token identity.

To mitigate rate abuse with Bearer tokens in NestJS, apply rate limiting scoped to the token or the identity within the token, and layer limits at global, route, and user levels. The examples below use the built-in ThrottlerGuard and ThrottlerService, which allow you to define custom scope keys so that limits are applied per token or per user.

1) Global token-aware rate limit with a dynamic scope key. This example demonstrates a custom extractor that reads the Bearer token and uses it as the scope key, ensuring each token has its own rate bucket.

// src/throttler/token-throttler-extractor.interceptor.ts
import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';
import { Request } from 'express';
import { ThrottlerGuard } from '@nestjs/throttler';

@Injectable()
export class TokenThrottlerInterceptor implements NestInterceptor {
  constructor(private readonly throttler: ThrottlerGuard) {}

  async intercept(context: ExecutionContext, next: CallHandler): Promise> {
    const req = context.switchToHttp().getRequest();
    const token = this.extractBearerToken(req);
    // Use token as scope key so limits apply per token
    context.switchToHttp().overrides.set('throttlerScope', token || 'anonymous');
    return this.throttler.intercept(context, next);
  }

  private extractBearerToken(req: Request): string | null {
    const auth = req.headers.authorization;
    if (typeof auth === 'string' && auth.startsWith('Bearer ')) {
      return auth.slice(7);
    }
    return null;
  }
}

2) Apply the interceptor and throttler globally with per-token buckets in your AppModule, alongside a route-specific exception for public endpoints that should remain unthrottled.

// src/app.module.ts
import { Module } from '@nestjs/common';
import { APP_INTERCEPTOR } from '@nestjs/core';
import { ThrottlerModule, ThrottlerGuard } from '@nestjs/throttler';
import { TokenThrottlerInterceptor } from './throttler/token-throttler-extractor.interceptor';

@Module({
  imports: [ThrottlerModule.register()],
  providers: [
    ThrottlerGuard,
    {
      provide: APP_INTERCEPTOR,
      useClass: TokenThrottlerInterceptor,
    },
  ],
})
export class AppModule {}

3) Configure store and limits in a ThrottlerModule.forRoot() setup that uses a Redis store for distributed consistency and defines distinct limits for authenticated token usage versus anonymous paths.

// src/throttler/throttler-config.module.ts
import { Module } from '@nestjs/common';
import { ThrottlerModule } from '@nestjs/throttler';
import { RedisStore } from 'rate-limit-redis';
import { createClient } from 'redis';

@Module({
  imports: [
    ThrottlerModule.registerAsync({
      imports: [],
      useFactory: () => ({
        ttl: 60, // 1 minute window
        limit: 100, // 100 requests per token per window
        store: new RedisStore({
          client: createClient({ url: 'redis://localhost:6379' }),
          keyPrefix: 'nestjs_throttle',
        }),
      }),
    }),
  ],
})
export class ThrottlerConfigModule {}

4) Route-level exceptions for public endpoints, and stricter limits for sensitive routes that accept or modify data. This example shows a stricter policy on write operations while allowing higher limits for read-only public routes.

// src/auth/auth.controller.ts
import { Controller, UseInterceptors, Get, Post, Req } from '@nestjs/common';
import { TokenThrottlerInterceptor } from '../throttler/token-throttler-extractor.interceptor';
import { ThrottlerGuard } from '@nestjs/throttler';

@Controller('items')
export class ItemsController {
  constructor(private readonly throttler: ThrottlerGuard) {}

  @UseInterceptors(TokenThrottlerInterceptor)
  @Get('public')
  publicQuery(@Req() req) {
    // Higher limit or bypass for public reads if needed via custom guard logic
    return { data: 'public items' };
  }

  @UseInterceptors(TokenThrottlerInterceptor)
  @Post('private')
  async createPrivate(@Req() req) {
    // Stricter limits enforced via per-token bucket
    return { ok: true };
  }
}

These patterns ensure that Bearer tokens are considered in rate-limiting decisions, reducing the risk of token-based rate abuse. Combine this with monitoring of token usage patterns to detect anomalies such as sudden spikes from a single token, which may indicate token leakage or automated abuse.