Api Key Exposure in Nestjs with Cockroachdb

When a NestJS application connects to CockroachDB, mishandling of database credentials and connection strings can lead to API key exposure. Because CockroachDB uses a PostgreSQL-compatible wire protocol, common patterns for loading connection configuration from environment variables are typical. If developers accidentally log configuration objects, serialize process.env, or expose debug endpoints that print the full database configuration, API keys or long-lived credentials used for CockroachDB authentication can leak into logs, error traces, or client-side responses.

In NestJS, the Data Access Layer often centralizes database connections using the @nestjs/typeorm or @nestjs/mongoose modules, where an injected data source or connection may include a password or auth token. If a developer injects the configuration object directly into a service and that service is used inside a controller with verbose error handling, a stack trace or console.log that includes the configuration can expose the API key. CockroachDB connection URIs typically embed the password; if that URI is stored in environment variables and then printed in error messages or health-check responses, the API key is effectively exposed to anyone who can trigger or view that output.

Additionally, if the application provides an endpoint for debugging or introspection that dumps the current module metadata or configuration, it may inadvertently surface the database credentials. This is especially risky when the application runs in environments where logs are aggregated and accessible to multiple teams or when error tracking services capture full request and response payloads. An attacker who can trigger an unhandled exception or force a debug route may receive the raw configuration that includes the CockroachDB API key, enabling unauthorized access to the cluster.

To illustrate, consider an example where a developer builds the TypeORM options dynamically in NestJS and logs them during startup. If the log is captured by an external monitoring service, the API key is stored in plaintext alongside the rest of the configuration. The same risk applies if the application uses a custom configuration service that merges process.env values into a single object and exposes it via an HTTP endpoint for troubleshooting purposes.

Secure handling of CockroachDB credentials in NestJS requires isolating sensitive values from runtime objects and ensuring they are never serialized into logs or exposed through endpoints. Use environment variables for secrets, but avoid passing the full configuration object through services that may be inspected or logged. Instead, construct connection options in a dedicated, minimal module that does not expose the password beyond the initialization step.

Below is a secure NestJS module that configures a TypeORM connection to CockroachDB without leaking credentials. It reads the password from process.env and uses it only to build the connection, avoiding inclusion of the password in objects that could be serialized or logged.

// cockroachdb-config.module.ts
import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';

@Module({
  imports: [
    TypeOrmModule.forRoot({
      type: 'cockroachdb',
      host: process.env.COCKRACKDB_HOST || 'localhost',
      port: Number(process.env.COCKRACKDB_PORT) || 26257,
      username: process.env.COCKRACKDB_USER || 'root',
      password: process.env.COCKRACKDB_PASSWORD, // injected, not logged
      database: process.env.COCKRACKDB_NAME,
      entities: [],
      synchronize: false,
      // Ensure logging is production-safe
      logger: ['error', 'warn'],
    }),
  ],
})
export class CockroachdbConfigModule {}

In this pattern, the password is passed as a string and never added to a broader configuration object that might be inspected. Avoid creating a service that returns the full TypeORM options, and do not include the password in error responses or debugging payloads.

For error handling, sanitize stack traces in production to prevent leakage of environment variables. Configure NestJS to hide sensitive fields when an error is thrown. Below is an example of a global filter that removes the password from any thrown exception’s message when running outside development mode.

// http-exception.filter.ts
import { ExceptionFilter, Catch, ArgumentsHost, HttpException } from '@nestjs/common';
import { Request, Response } from 'express';

@Catch()
export class AllExceptionsFilter implements ExceptionFilter {
  catch(exception: unknown, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();
    const request = ctx.getRequest();

    const status = exception instanceof HttpException ? exception.getStatus() : 500;
    const message = exception instanceof Error ? exception.message : 'Internal server error';

    // Do not expose stack or config in production
    const shouldHideDetails = process.env.NODE_ENV !== 'development';
    const body = shouldHideDetails
      ? { status, message: 'An internal error occurred' }
      : { status, message, path: request.url, timestamp: new Date().toISOString() };

    response.status(status).json(body);
  }
}

Finally, validate and restrict the source of environment variables. Use runtime checks to ensure required variables are present and avoid falling back to unsafe defaults that may be guessable. This prevents accidental usage of empty or placeholder credentials that could cause the client to connect without proper authentication, leading to verbose errors that reveal configuration details.