Api Key Exposure in Nestjs with Mysql

When an API built with NestJS interacts with a MySQL database, improper handling of sensitive values such as API keys can lead to exposure through multiple vectors. A common pattern is storing third-party service keys in a database table, such as integration_keys, and retrieving them at runtime. If the NestJS application does not enforce strict field-level filtering, a weakly designed GraphQL or REST endpoint may return rows that include the key column to unauthenticated or insufficiently authorized users.

Another path involves logging and error handling. If a MySQL error reveals query text or table structures, and the NestJS handler includes the full query or raw database response in logs or error messages, an API key may be leaked through stack traces or application logs. Misconfigured TypeORM or raw query result serialization can also expose columns that should be omitted, especially when using SELECT * patterns.

SSRF scenarios compound this risk. A compromised endpoint that accepts a hostname or URL parameter could be directed toward internal MySQL-compatible services, and a leaked API key might be used to pivot to other systems. MiddleBrick’s checks include unauthenticated endpoint detection and data exposure analysis, which can surface endpoints that return credentials or overly broad data sets without authentication.

Additionally, if the NestJS application uses environment variables to build MySQL connection strings and those values are mistakenly interpolated into responses or debug output, the key can be exposed in transit. MiddleBrick’s encryption and data exposure checks look for such leakage in both application responses and metadata returned by the API surface.

Apply strict column selection and omit sensitive fields in queries. Instead of SELECT *, explicitly list columns and exclude API keys. Use parameterized queries to prevent injection and accidental exposure through error messages.

import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { IntegrationKey } from './integration-key.entity';

@Injectable()
export class SecretsService {
  constructor(
    @InjectRepository(IntegrationKey)
    private readonly keysRepo: Repository,
  ) {}

  async getPublicConfig(tenantId: string) {
    // Explicitly exclude the key column from general queries
    return this.keysRepo
      .createQueryBuilder('ik')
      .select(['ik.id', 'ik.tenantId', 'ik.serviceName', 'ik.createdAt'])
      .where('ik.tenantId = :tenantId', { tenantId })
      .getMany();
  }

  async getKeyById(id: number) {
    // Retrieve key only when necessary and with proper authorization checks
    const row = await this.keysRepo
      .createQueryBuilder('ik')
      .select(['ik.id', 'ik.keyValue'])
      .where('ik.id = :id', { id })
      .getRawOne();
    if (!row) {
      throw new NotFoundException('Key not found');
    }
    return row;
  }
}

-- Example MySQL account for the NestJS app (run in MySQL shell)
CREATE USER 'nest_app'@'app-host' IDENTIFIED BY 'StrongPassword123!';
GRANT SELECT (id, tenant_id, service_name, created_at), INSERT, UPDATE ON app_db.integration_keys TO 'nest_app'@'app-host';
-- Explicitly deny SELECT on the key column for non-privileged roles
REVOKE SELECT ON app_db.integration_keys.key_value FROM 'nest_app'@'app-host';
FLUSH PRIVILEGES;

// Good practice: sanitize output before logging or returning
const safeForLogging = {
  id: result.id,
  service: result.serviceName,
  hasKey: !!result.keyValue,
};
console.info('Key access checked', safeForLogging);