Api Key Exposure in Express with Mysql

When an Express application manages database credentials for a Mysql connection, improper handling can lead to API key exposure. This typically occurs when keys are embedded in application code, stored in insecure configuration files, or logged inadvertently. In an Express backend that connects to Mysql, developers often place connection credentials and API keys in JavaScript files or environment loading logic. If these files are served statically or if error messages reveal filesystem paths, an attacker can recover the keys.

An Express route that constructs SQL strings by concatenating user input is vulnerable to injection, which can be chained to read source code or configuration files containing sensitive keys. For example, a crafted request might exploit a SQL injection flaw to access files through features like LOAD_FILE or by leveraging error messages that disclose absolute paths to configuration files. The Mysql driver in Node.js does not inherently sanitize these exposures; it simply passes queries to the server, so unsafe patterns in Express route handlers become the vector.

Environment variables are commonly used to store API keys for Mysql connections in Express, but they can leak through debug endpoints, verbose error pages, or misconfigured logging. If an Express app exposes a route like /debug that prints process.env, keys for the Mysql instance can be harvested. Similarly, stack traces in development mode may reveal file system locations where keys are stored, enabling further exploitation.

The risk is compounded when the same Express process connects to multiple services, as a single exposed key may grant access to related resources. Because middleBrick scans unauthenticated attack surfaces, it can detect endpoints that leak environment details or configuration snippets, flagging API key exposure as a high-severity finding. The scanner cross-references these runtime observations with the OpenAPI spec to identify discrepancies, such as undocumented debug routes or overly permissive CORS settings that facilitate key extraction.

To contextualize the impact, consider a scenario where an Express route queries Mysql using concatenated strings:

app.get('/user', (req, res) => {
  const userId = req.query.id;
  const query = 'SELECT * FROM users WHERE id = ' + userId;
  connection.query(query, (err, results) => {
    if (err) return res.status(500).send(err);
    res.json(results);
  });
});

If this route is reachable during a scan, middleBrick can manipulate the id parameter to trigger errors that expose file paths. Those paths may point to configuration files containing Mysql credentials or API keys. The tool also tests for missing authentication on administrative endpoints that could return environment variables, directly highlighting API key exposure in its prioritized findings with remediation guidance.

Securing Express applications that interact with Mysql requires strict separation of credentials from code, safe query construction, and controlled exposure of environment details. Use parameterized queries to prevent injection-driven key leakage, store secrets outside the application directory, and restrict debug output in production.

First, manage Mysql credentials via environment variables loaded from a file excluded from version control, and access them through process.env without exposing them in error responses. For example, configure your connection like this:

const mysql = require('mysql2/promise');

const pool = mysql.createPool({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME,
  waitForConnections: true,
  connectionLimit: 10,
});

module.exports = pool;

Ensure that .env is listed in .gitignore and never committed. In production, inject these variables through the hosting platform’s secrets manager rather than hardcoding them.

Second, avoid string concatenation when building queries. Use prepared statements to keep SQL and data distinct, which prevents attackers from altering query logic to read sensitive files or keys:

app.get('/user', async (req, res) => {
  try {
    const [results] = await pool.execute(
      'SELECT id, name FROM users WHERE id = ?',
      [req.query.id]
    );
    res.json(results);
  } catch (err) {
    res.status(500).json({ error: 'Request failed' });
  }
});

This pattern ensures that user input cannot change the structure of the SQL, mitigating injection paths that might lead to API key exposure. The pool-based approach also centralizes credential usage, making audits easier.

Third, disable verbose error messages and avoid exposing stack traces in responses. Use a centralized error handler that logs details for developers without returning sensitive paths or environment content to clients:

app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ error: 'Internal server error' });
});

Additionally, remove or protect debug endpoints that print environment variables. If such endpoints are necessary for troubleshooting, restrict them to internal networks or authenticated administrative interfaces, and ensure they are included in the API specification so that middleBrick can validate their exposure level during scans.

Finally, rotate keys regularly and apply principle of least privilege to Mysql accounts used by Express. Restrict host access and permissions for the user connecting to Mysql so that even if a key is exposed, the blast radius is limited. The combination of secure coding, secret management, and careful endpoint design reduces the likelihood of API key exposure and aligns with findings that middleBrick reports with actionable remediation guidance.