Brute Force Attack in Nestjs with Hmac Signatures

A brute force attack against an API that uses Hmac signatures in a NestJS application typically targets the signature verification logic or the nonce/timestamp validation rather than the cryptographic primitive itself. When Hmac is implemented naively, patterns emerge that an attacker can abuse without needing the secret key.

Consider a NestJS controller that expects an X-API-Signature header built from a request payload, a timestamp, and a nonce. If the endpoint does not enforce strict uniqueness constraints on the nonce or does not reject requests with timestamps that are too far out of sync, an attacker can systematically submit the same payload with different nonces or slightly altered timestamps. Because each distinct combination produces a valid Hmac, the server may treat each attempt as a new, legitimate request rather than a sign of credential abuse.

Another vector arises when the application exposes a high-throughput endpoint that accepts Hmac-signed requests but lacks rate limiting. An attacker can perform a large number of offline Hmac calculations (using guessed or known data) and then flood the endpoint with valid signatures. Even though Hmac prevents forging without the secret, the volume of acceptable requests can exhaust resources or reveal timing differences that aid further exploitation.

In some cases, the signature is computed over a subset of request parameters while other parameters are passed unchecked. An attacker can brute force unchecked parameters—such as identifiers or action types—while keeping the signed portion constant. If the server applies authorization or business logic based on those unchecked values after verifying the Hmac, the attacker can iterate over possibilities to access or manipulate data that should be restricted.

NestJS middleware or guards that validate Hmac may also inadvertently disclose whether a signature is well-formed before performing deeper checks. Distinct error messages for malformed signatures versus unauthorized actions allow an attacker to refine guesses and automate a brute force campaign with feedback from the API. Without uniform error handling and strict input validation, the effective search space for an attacker shrinks, making brute force more practical.

These issues are not inherent to Hmac, but to how NestJS applications integrate it. The attack surface grows when nonces, timestamps, and rate controls are inconsistent, when signatures cover only partial requests, or when error handling leaks validation state. Proper design ensures that each signed interaction is unique, bounded, and verified before any business logic proceeds.

Remediation centers on making each Hmac verification strict, idempotent, and resistant to enumeration. The following examples show a hardened approach in NestJS.

First, enforce a short timestamp window and a server-side store of used nonces to prevent replay and brute force attempts:

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

@Injectable()
export class HmacValidationMiddleware implements NestMiddleware {
  private usedNonces = new Set();
  private readonly TIME_WINDOW = 300; // 5 minutes
  private readonly NONCE_TTL = 300;   // seconds to retain nonce

  use(req: Request, res: Response, next: NextFunction) {
    const signature = req.headers['x-api-signature'] as string | undefined;
    const nonce = req.headers['x-api-nonce'] as string | undefined;
    const timestamp = req.headers['x-api-timestamp'] as string | undefined;

    if (!signature || !nonce || !timestamp) {
      return this.fail(res, 400, 'Missing required headers');
    }

    const now = Math.floor(Date.now() / 1000);
    const requestTime = parseInt(timestamp, 10);
    if (isNaN(requestTime) || Math.abs(requestTime - now) > this.TIME_WINDOW) {
      return this.fail(res, 400, 'Timestamp out of range');
    }

    if (this.usedNonces.has(nonce)) {
      return this.fail(res, 400, 'Duplicate nonce');
    }

    // Store nonce with cleanup to avoid unbounded growth
    this.usedNonces.add(nonce);
    setTimeout(() => this.usedNonces.delete(nonce), this.NONCE_TTL * 1000);

    const expected = this.computeSignature(req, process.env.HMAC_SECRET!);
    if (!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
      return this.fail(res, 401, 'Invalid signature');
    }

    next();
  }

  private computeSignature(req: Request, secret: string): string {
    const base = [
      req.method.toUpperCase(),
      req.path,
      req.headers['x-api-timestamp'],
      req.headers['x-api-nonce'],
      typeof req.body === 'string' ? req.body : JSON.stringify(req.body),
    ].join('|');
    return crypto.createHmac('sha256', secret).update(base).digest('hex');
  }

  private fail(res: Response, code: number, message: string) {
    res.status(code).json({ error: message });
  }
}

Second, ensure the signature covers all meaningful inputs and avoid branching logic that reveals validation state:

import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';
import crypto from 'crypto';

@Injectable()
export class HmacInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable {
    const request = context.switchToHttp().getRequest();
    const signature = request.headers['x-api-signature'] as string;
    const nonce = request.headers['x-api-nonce'] as string;
    const timestamp = request.headers['x-api-timestamp'] as string;

    const payload = this.getRequestPayload(request);
    const computed = this.sign(payload, nonce, timestamp, process.env.HMAC_SECRET!);

    if (!this.timingSafeCompare(signature, computed)) {
      throw new Error('Unauthorized');
    }

    return next.handle();
  }

  private getRequestPayload(req: any): string {
    // Normalize and include all relevant parts
    const body = typeof req.body === 'string' ? req.body : JSON.stringify(req.body || {});
    return [req.method.toUpperCase(), req.path, req.headers['x-api-timestamp'], req.headers['x-api-nonce'], body].join('|');
  }

  private sign(...parts: string[]): string {
    return crypto.createHmac('sha256', process.env.HMAC_SECRET!).update(parts.join('|')).digest('hex');
  }

  private timingSafeCompare(a: string, b: string): boolean {
    return crypto.timingSafeEqual(Buffer.from(a), Buffer.from(b));
  }
}

Third, apply global rate limiting and require Hmac for all mutating methods. Combine with idempotency keys where applicable to prevent duplicate processing from replayed requests:

import { RateLimiterMemory } from 'rate-limiter-flexible';

const rateLimiter = new RateLimiterMemory({
  points: 100,      // 100 requests
  duration: 1,      // per second
});

// In a route or middleware
async function handle(req: Request, res: Response, next: NextFunction) {
  try {
    await rateLimiter.consume(req.ip);
    next();
  } catch (_) {
    res.status(429).json({ error: 'Too many requests' });
  }
}

Finally, map findings to compliance frameworks such as OWASP API Top 10 (2023) A07:2021 – Identification and Authentication Failures and A05:2021 – Broken Function Level Authorization. These examples show how Hmac-specific controls reduce brute force feasibility by eliminating nonces reuse, bounding timestamps, and ensuring uniform error handling.