Api Key Exposure in Nestjs

Api Key Exposure in Nestjs applications typically occurs through several Nestjs-specific patterns. The most common vulnerability appears in authentication middleware where API keys are handled insecurely. Consider a typical Nestjs authentication guard:

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

@Injectable()
export class ApiKeyGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    const apiKey = request.headers['x-api-key'];
    
    // Vulnerable: API key logged in plaintext
    console.log(`API Key: ${apiKey}`);
    
    // Vulnerable: API key passed to service without validation
    return this.authService.validateApiKey(apiKey);
  }
}

This pattern exposes API keys through multiple attack vectors. First, console logging creates log files containing plaintext API keys that may be accessible to attackers with file system access. Second, passing API keys directly to services without proper validation allows them to propagate through the application stack.

Another Nestjs-specific manifestation occurs in interceptors and filters. Consider this error handling filter:

import { ArgumentsHost, Catch, ExceptionFilter } from '@nestjs/common';

@Catch()
export class ApiKeyErrorFilter implements ExceptionFilter {
  catch(exception: unknown, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();
    const request = ctx.getRequest();
    
    // Vulnerable: API key included in error response
    response.status(500).json({
      error: 'Internal Server Error',
      api_key: request.headers['x-api-key'], // Exposed!
      timestamp: new Date().toISOString(),
    });
  }
}

Here, the API key is deliberately included in error responses, creating a direct exposure vector. Attackers can trigger error conditions to harvest API keys from response bodies.

Configuration management in Nestjs also creates exposure risks. Many applications use environment variables for API keys:

// environment.ts
export const environment = {
  apiKey: process.env.API_KEY, // May be undefined
};

// auth.service.ts
import { environment } from '../environment';

@Injectable()
export class AuthService {
  validateApiKey(key: string): boolean {
    // Vulnerable: comparing undefined with hardcoded value
    return key === environment.apiKey;
  }
}

If the environment variable is undefined or misconfigured, the application may accept any API key, creating a complete authentication bypass.

Detecting API key exposure in Nestjs applications requires examining both code patterns and runtime behavior. The middleBrick scanner identifies Nestjs-specific vulnerabilities through several mechanisms:

Code Pattern Analysis - middleBrick's OpenAPI/Swagger spec analysis resolves $ref definitions and examines authentication schemas. For Nestjs applications, it looks for:

// middleBrick scan output for a vulnerable endpoint
{
  "endpoint": "/api/data",
  "method": "GET",
  "authentication": "API Key in header",
  "vulnerability": "ApiKeyExposure",
  "severity": "High",
  "evidence": "API key logged in auth guard",
  "remediation": "Remove console.log statements containing API keys"
}

Runtime Scanning - middleBrick tests unauthenticated endpoints and examines responses for exposed credentials. For Nestjs applications, it specifically probes:

• Authentication endpoints for API key leakage in responses
• Error responses that might contain API keys
• Health check endpoints that may expose configuration
• Documentation endpoints (Swagger UI) that might reveal API key formats

Configuration Analysis - middleBrick examines environment variable usage patterns common in Nestjs:

// Detected vulnerability in environment configuration
{
  "type": "ConfigurationExposure",
  "location": "environment.ts",
  "issue": "API key may be undefined",
  "risk": "Authentication bypass possible",
  "fix": "Implement proper environment validation"
}

The scanner also tests for common Nestjs middleware patterns that may expose API keys. For example, it identifies when API keys are passed through multiple layers without proper sanitization.

Securing API keys in Nestjs requires leveraging the framework's built-in features and following security best practices. Here are Nestjs-specific remediation patterns:

Secure Authentication Guard - Use Nestjs's CanActivate interface with proper validation:

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

@Injectable()
export class SecureApiKeyGuard implements CanActivate {
  constructor(private configService: ConfigService) {}

  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    const apiKey = request.headers['x-api-key'];
    
    // Secure: validate without logging
    const validKey = this.configService.get('API_KEY');
    if (!apiKey || apiKey !== validKey) {
      return false;
    }
    
    // Secure: store in request context, not logs
    request.apiKeyValidated = true;
    return true;
  }
}

Secure Error Handling - Create a Nestjs exception filter that redacts sensitive data:

import { ArgumentsHost, Catch, ExceptionFilter } from '@nestjs/common';

@Catch()
export class SecureExceptionFilter implements ExceptionFilter {
  catch(exception: unknown, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();
    
    // Secure: never include API keys in responses
    response.status(500).json({
      error: 'Internal Server Error',
      message: 'An error occurred',
      timestamp: new Date().toISOString(),
    });
  }
}

Configuration Validation - Use Nestjs's ConfigModule with validation:

import { Module, forwardRef } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import * as Joi from 'joi';

const configValidation = Joi.object({
  API_KEY: Joi.string().required().description('API key for authentication'),
  NODE_ENV: Joi.string().valid('development', 'production').default('development'),
});

@Module({
  imports: [
    ConfigModule.forRoot({
      validationSchema: configValidation,
      validationOptions: {
        allowUnknown: true,
        abortEarly: true,
      },
    }),
  ],
})
export class AppModule {}

Logging Security - Configure Nestjs's logging to redact sensitive data:

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

export class SecureLogger extends Logger {
  log(message: string, context?: string) {
    // Secure: remove any API key patterns before logging
    const sanitized = message.replace(/(x-api-key: )?\w{32}/g, '[REDACTED]');
    super.log(sanitized, context);
  }
}

Middleware Security - Create secure middleware for API key handling:

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

@Injectable()
export class ApiKeyMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    const apiKey = req.headers['x-api-key'];
    
    // Secure: validate and store securely
    if (!this.validateApiKey(apiKey)) {
      res.status(401).json({ error: 'Invalid API key' });
      return;
    }
    
    // Secure: attach to request without exposing
    req.user = { authenticated: true };
    next();
  }

  private validateApiKey(key: string): boolean {
    // Implement secure validation logic
    return key === process.env.API_KEY;
  }
}