Api Key Exposure in Express with Mssql

When an Express application interacts with Microsoft SQL Server via the mssql package, api key exposure often arises from how connection configurations and runtime data flow between the web layer and the database layer. Because Express handles HTTP requests directly, any route that builds a mssql connection config using values from request parameters, headers, or query strings can inadvertently surface sensitive credentials or connection strings in logs, error messages, or client responses.

For example, if an endpoint accepts a database name or instance name from the client and interpolates it into a mssql config, an attacker can probe for differences in error timing or content to infer valid instance names or gain insight into how credentials are sourced. A typical vulnerable pattern is constructing a config object with inline credentials or connection strings derived from environment variables that are accidentally passed to the response body in error handling paths.

Another common exposure vector is verbose error messages returned by mssql when connection attempts fail. By default, the mssql library may include details such as server names, instance names, or parts of connection strings in thrown errors. If Express does not sanitize these errors before sending them to the client, an attacker can harvest information that facilitates further reconnaissance or credential brute-forcing.

Additionally, if the Express app reuses a single mssql connection pool across requests and logs pool events or query metadata without redaction, api keys or other sensitive tokens can appear in application logs or monitoring outputs. This is especially risky in shared environments where log aggregation systems are used. The risk is not in the mssql driver itself, but in how the Express app constructs, transports, and logs data involving connection credentials.

To illustrate, consider an endpoint that dynamically builds a mssql config from request input without strict validation:

const sql = require('mssql');

app.get('/query/:table', async (req, res) => {
  const { table } = req.params;
  const config = {
    user: process.env.DB_USER,
    password: process.env.DB_PASSWORD,
    server: process.env.DB_SERVER,
    database: table, // risky: using user input as database name
    options: {
      encrypt: true
    }
  };

  try {
    const pool = await sql.connect(config);
    const result = await pool.request().query(`SELECT * FROM ${table}`);
    res.json(result.recordset);
  } catch (err) {
    res.status(500).json({ error: err.message }); // may expose sensitive details
  } finally {
    sql.close();
  }
});

In this snippet, the database field is taken directly from user input, and the catch block returns the raw error message. If the error includes a connection string or credential hint, the client can learn details about the database topology or authentication mechanism. Over time, such patterns increase the likelihood of api key exposure through accidental leakage in logs or responses.

Remediation focuses on strict input validation, safe configuration handling, and robust error sanitization. Always treat user input as untrusted, and never allow it to directly shape sensitive parts of the mssql configuration such as credentials or database names unless those values are rigorously enumerated against a whitelist.

Use environment variables for credentials and avoid constructing connection strings from request data. If dynamic database routing is required, map incoming identifiers to predefined, validated database names:

const sql = require('mssql');

const allowedDatabases = ['appdb', 'reportdb', 'auditdb'];

app.get('/query/:table', async (req, res) => {
  const { table } = req.params;
  const dbName = req.query.db;

  if (!allowedDatabases.includes(dbName)) {
    return res.status(400).json({ error: 'invalid database' });
  }

  const config = {
    user: process.env.DB_USER,
    password: process.env.DB_PASSWORD,
    server: process.env.DB_SERVER,
    database: dbName,
    options: {
      encrypt: true,
      trustServerCertificate: false
    }
  };

  let pool;
  try {
    pool = await sql.connect(config);
    const sanitizedTable = table.replace(/[^a-zA-Z0-9_]/g, '');
    const result = await pool.request().query(`SELECT * FROM [${sanitizedTable}]`);
    res.json(result.recordset);
  } catch (err) {
    // Log full error for debugging, but return generic message to client
    console.error('Database error:', err.name, err.code);
    res.status(500).json({ error: 'request failed' });
  } finally {
    try {
      await sql.close();
    } catch (_) {}
  }
});

Key practices in this remediation include:

• Whitelist validation: Only allow specific, known-safe database names instead of passing raw user input to mssql.
• Input sanitization: Strip or escape unsafe characters from identifiers used in queries to reduce injection surface.
• Error handling discipline: Avoid exposing raw mssql error details to clients; log internally for investigation but return generic responses.
• Secure connection options: Set trustServerCertificate to false in production to enforce proper TLS validation, reducing the risk of downgrade or interception attacks that could expose credentials.

For applications using the middleBrick CLI to validate their endpoints, running middlebrick scan <url> can help detect whether error messages or configuration patterns risk exposing sensitive details. Teams on the Pro plan can enable continuous monitoring to catch regressions early, while the GitHub Action can block merges if scans exceed defined security thresholds.