Api Key Exposure in Nestjs with Api Keys

API keys are a common bearer credential used to control access and track usage. In NestJS applications, keys are often passed via headers (e.g., x-api-key), query parameters, or environment variables. When API key handling is not carefully designed, the application can inadvertently expose keys or accept them in ways that increase risk. For example, logging raw headers, reflecting keys in error messages, or failing to restrict key transmission channels can create exposure paths. Another common pattern is using API keys for authorization without also enforcing proper authentication context, which can lead to privilege confusion or insecure direct object references (BOLA/IDOR) when keys are tied to tenant or user identifiers.

Endpoints that accept API keys in query strings are especially prone to accidental leakage in logs, browser history, or referrer headers. If a NestJS route uses a key only for rate limiting or identification but then passes sensitive data in responses without additional authorization, an attacker who observes or guesses a valid key may infer data access patterns or harvest information through enumeration. Keys embedded in frontend code or client-side JavaScript are trivially discoverable and should never be used as the sole gatekeeper for sensitive operations. MiddleBrick’s API scans detect these exposure patterns by correlating OpenAPI specs with runtime behavior—such as unauthenticated endpoints that still require a key or endpoints that echo key material in responses—surfacing findings under Data Exposure and Authentication checks.

SSRF and unsafe consumption amplify key exposure risks. A NestJS service that forwards requests based on user-supplied URLs or headers might inadvertently route to internal metadata services where instance credentials or keys are accessible. Similarly, integrations with third-party APIs that use key-based auth can leak keys if error handling includes stack traces or verbose responses containing the key. The LLM/AI Security checks in MiddleBrick specifically look for scenarios where key handling logic could be tricked via prompt injection or where key-like strings appear in model outputs, helping identify subtle channels where keys might be exfiltrated.

Compliance mappings such as OWASP API Top 10 (2023) highlight that broken object level authorization and excessive data exposure often intersect with weak API key usage. PCI-DSS and SOC2 similarly expect keys to be protected in transit and at rest, with strict controls over who and what can access them. MiddleBrick reports include these framework references and provide prioritized remediation guidance so teams can focus on the most impactful changes first.

Remediation focuses on reducing the key’s exposure surface and ensuring keys are never treated as a sole authorization mechanism. Use HTTP-only, Secure cookies for browser-facing flows where feasible, or require keys to be passed only via the Authorization header using a scheme like Bearer or a custom scheme that your middleware normalizes. Avoid echoing keys in responses or logs, and enforce strict CORS and referrer policies to limit leakage via browser channels.

Example: Define a guard that checks for a key in the Authorization header using a custom scheme, without logging the key value.

import { Injectable, CanActivate, ExecutionContext, ForbiddenException } from '@nestjs/common';
import { Request } from 'express';

@Injectable()
export class ApiKeyGuard implements CanActivate {
  private readonly validKeys = new Set([process.env.API_KEY_1, process.env.API_KEY_2]);

  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest<Request>();
    const auth = request.headers['authorization'] || '';
    // Expected format: "Key {key}"
    const [scheme, key] = auth.split(' ');
    if (scheme !== 'Key' || !key || !this.validKeys.has(key)) {
      throw new ForbiddenException('Invalid API key');
    }
    // Do not log the key
    return true;
  }
}

Example: Use environment variables and a configuration service so keys are not hard-coded or accidentally serialized in error objects.

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

@Injectable()
export class ConfigService {
  private readonly apiKeys: string[] = [
    process.env.API_KEY_PROD ?? '',
    process.env.API_KEY_STAGING ?? '',
  ].filter(Boolean) as string[];

  isValid(key?: string): boolean {
    return key ? this.apiKeys.includes(key) : false;
  }
}

Apply the guard globally or per-controller to ensure keys are validated consistently, and combine with role-based or tenant-based checks to prevent BOLA/IDOR where a key is valid but the caller should not access a specific resource. Rate limiting and monitoring should be key-aware without storing keys in plaintext logs; instead, hash keys before emitting any diagnostic events. MiddleBrick’s CLI can be used locally to verify that endpoints requiring keys are not also unauthenticated and that spec-defined security schemes align with runtime behavior.

In CI/CD, the GitHub Action can enforce that any new or modified OpenAPI spec includes security schemes for API keys and that scans meet your risk threshold. For long-running services, the Pro plan’s continuous monitoring will alert you if new endpoints appear that accept keys without proper authorization, giving you time to remediate before exposure widens.