Injection Flaws in Express (Javascript)

Injection flaws in Express with JavaScript commonly arise when user-controlled input is concatenated into commands or queries without validation or parameterization. In a JavaScript/Node context, this often means building dynamic strings for database queries, shell commands, or eval-like operations. Because JavaScript is dynamically typed, it is easy to construct expressions that look harmless but can be coerced into executing unintended logic.

Express applications frequently interact with databases, operating system utilities, or template engines. If request parameters, headers, or body values are used to construct queries or command-line arguments, an attacker can supply payloads that change the intended structure. For example, a login route that builds a SQL string via concatenation can be bypassed using crafted input that comments out parts of the query or always returns true. Similarly, passing unsanitized input to child process functions can lead to command injection, allowing an attacker to execute arbitrary OS commands.

Template engines in Express, such as EJS or Pug, can also be a vector if they interpolate user input without proper escaping. This can lead to stored or reflected cross-site scripting (XSS), which can be chained with injection-like behavior in some contexts. Even JSON parsing can be risky if the application uses custom revivers or dynamically constructs code from parsed values.

Because Express does not enforce strict schema validation by default, developers must explicitly sanitize and validate inputs. Without strict type checks and allowlists, coercion rules in JavaScript can cause unexpected truthy/falsy outcomes that bypass intended checks. For instance, an array where a developer expects a string may be iterated or stringified in a way that introduces ambiguity. These subtleties make injection flaws particularly dangerous in JavaScript-based Express services.

middleBrick tests these scenarios by running input validation checks and observing whether endpoints reflect or execute injected payloads. It also examines OpenAPI specifications to see whether input constraints are formally defined and compares them against runtime behavior. This helps identify mismatches where documentation claims stricter types than the implementation enforces.

To mitigate injection flaws in Express with JavaScript, prefer parameterized APIs and strict input validation over string concatenation. Below are concrete, safe patterns and examples you can adopt.

1. Use parameterized queries for databases

Instead of building SQL strings, use prepared statements or query builders that enforce parameter separation. For example, with mysql2:

const mysql = require('mysql2/promise');
const express = require('express');
const app = express();
app.use(express.json());

app.post('/user', async (req, res) => {
  const { email } = req.body;
  const connection = await mysql.createConnection({ database: 'app' });
  // Safe: parameterized query
  const [rows] = await connection.execute(
    'SELECT id, name FROM users WHERE email = ?',
    [email]
  );
  await connection.end();
  res.json(rows);
});

2. Validate and sanitize all inputs

Use a validation library with allowlists and type coercion control. For instance, with express-validator:

const { body, validationResult } = require('express-validator');
const express = require('express');
const app = express();
app.use(express.json());

app.post('/user', [
  body('email').isEmail().normalizeEmail(),
  body('age').optional().isInt({ min: 0, max: 120 })
], (req, res) => {
  const errors = validationResult(req);
  if (!errors.isEmpty()) {
    return res.status(400).json({ errors: errors.array() });
  }
  // Safe to use req.body.email and req.body.age
  res.json({ email: req.body.email, age: req.body.age });
});

3. Avoid eval and dynamic code execution

Never use eval, setTimeout with string arguments, or the Function constructor with untrusted input:

const express = require('express');
const app = express();
app.use(express.json());

app.post('/calculate', (req, res) => {
  const { expression } = req.body;
  // Unsafe: do not do this
  // const result = eval(expression);
  // Safer alternative: use a well-audited expression parser
  res.json({ error: 'Use a safe parser instead of eval' });
});

4. Escape output in templates

If you use EJS, ensure autoescape is enabled or explicitly escape data:

<%- userProvidedContent %>  // EJS: escapes HTML
<%- someValue %>

5. Sanitize before shell commands

If you must invoke a subprocess, validate and escape arguments:

const { execFile } = require('child_process');
const express = require('express');
const app = express();
app.use(express.json());

app.get('/convert', (req, res) => {
  const filename = req.query.f;
  // Validate filename against an allowlist pattern
  if (!/^[a-zA-Z0-9._-]+$/.test(filename)) {
    return res.status(400).json({ error: 'Invalid filename' });
  }
  execFile('convert', [filename, 'out.png'], (err, stdout, stderr) => {
    if (err) return res.status(500).json({ error: 'Conversion failed' });
    res.json({ output: stdout });
  });
});

6. Enforce strict JSON parsing and type checks

Avoid custom revivers that execute code. Prefer JSON.parse with schema validation:

const Ajv = require('ajv');
const ajv = new Ajv();
const validate = ajv.compile({
  type: 'object',
  properties: {
    query: { type: 'string' },
    limit: { type: 'integer', minimum: 1, maximum: 100 }
  },
  required: ['query'],
  additionalProperties: false
});

app.post('/search', (req, res) => {
  const valid = validate(req.body);
  if (!valid) {
    return res.status(400).json({ errors: validate.errors });
  }
  res.json({ query: req.body.query });
});

These practices significantly reduce the risk of injection flaws. For ongoing assurance, middleBrick can scan your Express endpoints to verify that input constraints and validation logic align with your intended security posture.