Api Key Exposure in Nestjs with Mssql

When a NestJS application connects to Microsoft SQL Server using an integration package such as mssql or tedious, the framework and database driver do not inherently leak secrets. However, the way developers configure connection strings, manage environment variables, and handle runtime errors can unintentionally expose API keys or database credentials. A common pattern is storing a full connection string in environment variables (e.g., MSSQL_CONNECTION_STRING) and passing it directly to SqlConfig or ConnectionPool. If the application does not sanitize error messages, a failed connection can surface the full string in stack traces or HTTP responses, revealing embedded credentials.

In NestJS, developers often create a MssqlService using ConfigService to inject configuration. If the configuration is inadvertently exposed through an unguarded debug endpoint, a verbose error handler, or improper logging, an API key or connection string used for authentication can be returned to an unauthenticated client. The risk is higher when developers include sensitive values in structured configuration objects that are accidentally serialized into logs or HTTP responses. For example, logging the configuration object for debugging purposes can print the password or key to the console, which may be captured in centralized logging systems and accessed by unauthorized parties.

Another vector specific to this combination is dynamic connection string construction. If a NestJS service builds the connection string at runtime by concatenating user input or environment variables without validation, an attacker who can read environment variables (for example, through a compromised build pipeline or a misconfigured container) can leverage that to exfiltrate the key. The mssql library does not redact credentials, so any stack trace that includes a connection error may display the full URI, including the password or access token. This is particularly dangerous in containerized or serverless deployments where environment variables are mounted as files or injected via orchestration tools, and where log aggregation might inadvertently index sensitive strings.

Additionally, improper HTTP exception handling in NestJS can transform a database connectivity issue into a disclosure event. If global exception filters capture database errors and forward them to the client, the raw error object from the mssql driver may include connection parameters. For instance, a timeout or authentication failure from SQL Server can produce messages that reference the server name, database, and authentication context, providing clues that assist an attacker in refining their approach. Therefore, the NestJS layer must ensure that low-level driver errors are transformed into generic responses before reaching API consumers.

Compliance-aware developers should map this scenario to the OWASP API Security Top 10, specifically to API1:2023 Broken Object Level Authorization, where excessive data exposure through error messages can reveal sensitive configuration details. The use of a structured logger that redacts sensitive fields, combined with strict exception handling, is essential when working with database drivers like mssql in NestJS. MiddleBrick’s scans can detect whether error responses or documentation endpoints inadvertently disclose connection strings or API keys associated with SQL Server integrations.

Remediation focuses on isolating secrets from application logic, ensuring errors are sanitized, and validating configuration at startup. Store connection details outside the codebase using environment variables or a secrets manager, and never concatenate raw user input into connection strings. In NestJS, create a dedicated configuration module that reads and validates the presence of required variables without exposing them in logs.

// config/sql.config.ts
import { ConfigModule } from '@nestjs/config';

export const dbConfig = {
  options: {
    user: process.env.MSSQL_USER,
    password: process.env.MSSQL_PASSWORD,
    server: process.env.MSSQL_HOST,
    database: process.env.MSSQL_DATABASE,
    options: {
      encrypt: true,
      trustServerCertificate: false,
    },
  },
};

Use the built-in ConfigService to inject these values into your data service. This prevents accidental logging of the raw configuration object and keeps sensitive values out of component code.

// mssql.service.ts
import { Injectable } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import { ConnectionPool, Request } from 'mssql';

@Injectable()
export class MssqlService {
  constructor(private readonly configService: ConfigService) {}

  private async getPool(): Promise {
    const config = this.configService.get('db.options');
    return new ConnectionPool(config).connect();
  }

  async getUserRoles(): Promise {
    const pool = await this.getPool();
    const result = await pool.request().query('SELECT role_name FROM sys.database_roles');
    return result.recordset;
  }
}

Ensure that global exception filters do not pass through raw driver errors. Wrap mssql calls in try/catch blocks and return generic messages. Never forward stack traces containing connection strings to the client.

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

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

    if (exception instanceof HttpException) {
      response.status(exception.getStatus()).json({
        statusCode: exception.getStatus(),
        message: 'An error occurred',
      });
      return;
    }

    // Log the full error internally, but return a sanitized response
    console.error(exception);
    response.status(HttpStatus.INTERNAL_SERVER_ERROR).json({
      statusCode: HttpStatus.INTERNAL_SERVER_ERROR,
      message: 'Internal server error',
    });
  }
}

Validate environment variables at application bootstrap to fail fast if a required secret is missing, avoiding runtime errors that might expose configuration details.

// main.ts
import { ValidationPipe } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';\n
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  const configService = app.get(ConfigService);

  // Ensure required variables are present and non-empty
  const requiredVars = ['MSSQL_USER', 'MSSQL_PASSWORD', 'MSSQL_HOST', 'MSSQL_DATABASE'];
  requiredVars.forEach((v) => {
    if (!configService.get(v)) {
      throw new Error(`Missing required environment variable: ${v}`);
    }
  });

  app.useGlobalPipes(new ValidationPipe({ whitelist: true }));
  await app.listen(3000);
}
bootstrap();

Audit your logging configuration to ensure that request or error logs do not include query strings or configuration values. Redact any field that could contain a key or credential before writing to storage or external services.

By combining strict environment management, typed configuration, and sanitized error handling, you reduce the likelihood of API key exposure when integrating NestJS with Microsoft SQL Server. MiddleBrick’s continuous monitoring can verify that error responses remain generic and that no credentials are exposed in documentation or debug endpoints.