Data Exposure in Express (Javascript)

Express applications often inadvertently expose sensitive data through misconfigured routes, verbose error responses, or improper serialization of objects. Because Express is minimal and flexible, developers may assume certain data is private when it is actually accessible via HTTP. For example, returning a full Mongoose document or Sequelize model instance in a response can leak internal fields like passwordHash, resetToken, or __v if not explicitly filtered. Similarly, using res.json() on an object that contains getters or virtuals that access sensitive data can unintentionally expose them during serialization.

A common pattern is debugging middleware that logs or returns req.body, req.headers, or process.env in error handlers. In production, if NODE_ENV is not set to 'production', Express's default error handler may leak stack traces containing file paths, module names, and lines of code — information useful for attackers mapping the application surface. Another frequent issue is exposing configuration files via static serving; if app.use(express.static('public')) points to a directory containing .env, config.json, or id_rsa, those files become downloadable.

These exposures map to OWASP API Security Top 10:2023, A3:2023 – Broken Object Property Level Authorization, where excessive data is returned in responses. middleBrick detects such issues by scanning unauthenticated endpoints and analyzing response bodies for patterns indicative of secrets, tokens, or internal metadata, flagging them as data exposure findings with severity based on data type and context.

To prevent data exposure in Express, implement explicit response filtering, secure error handling, and strict static file serving. Never send raw model instances or request objects directly. Instead, use Data Transfer Objects (DTOs) or selective property extraction.

For example, when returning user data, explicitly select safe fields:

// Unsafe: exposes passwordHash, resetToken, etc.
app.get('/users/:id', async (req, res) => {
  const user = await User.findById(req.params.id);
  res.json(user); // DANGEROUS
});

// Safe: only expose intended fields
app.get('/users/:id', async (req, res) => {
  const user = await User.findById(req.params.id);
  if (!user) return res.sendStatus(404);
  res.json({
    id: user._id,
    username: user.username,
    email: user.email,
    createdAt: user.createdAt
  });
});

For error handling, disable detailed errors in production and use a custom handler that leaks no internal details:

// Secure error middleware
app.use((err, req, res, next) => {
  console.error(err); // Log internally
  const status = err.status || 500;
  const message = process.env.NODE_ENV === 'production'
    ? 'Internal Server Error'
    : err.message;
  res.status(status).json({ error: message });
});

// Ensure NODE_ENV is set
// In production: NODE_ENV=production node app.js

To serve static files safely, exclude sensitive directories and files:

const path = require('path');
const express = require('express');
const app = express();

// Serve only the public directory, dotfiles denied by default
app.use(express.static(path.join(__dirname, 'public')));

// Alternatively, explicitly deny sensitive patterns
app.use(express.static('public', {
  dotfiles: 'deny',
  index: false,
  redirectToSlash: true
}));

// Block access to .env, .git, etc. via middleware if needed
app.use((req, res, next) => {
  if (req.path.match(/\.(env|git|gitignore|yml|yaml|json)$/)) {
    return res.sendStatus(403);
  }
  next();
});

These practices ensure that only intended data is exposed, reducing the risk of accidental data leakage in Express applications.