Excessive Data Exposure in Express with Basic Auth

Excessive Data Exposure occurs when an API returns more information than necessary for a given operation, such as full database rows, stack traces, or internal identifiers. In Express applications that use HTTP Basic Authentication, this risk is compounded because the authentication mechanism transmits credentials in every request, and responses may inadvertently reveal sensitive data that should be constrained.

When an endpoint uses Basic Auth, the server decodes the base64-encoded credentials from the Authorization header but may still return verbose error messages or complete user records, including fields like password hashes, email addresses, or internal IDs. For example, a user profile endpoint that returns the full Mongoose document can expose fields such as __v, password, or role that are not intended for the client. An attacker who has obtained a valid credential pair might leverage overly detailed responses to map the application’s data model or identify privilege escalation paths.

Middleware that logs requests can also contribute to data exposure when combined with Basic Auth. If request bodies or query parameters containing sensitive information are written to logs, and those logs are accessible or aggregated, the combination of persistent credentials and logged data increases the window for information leakage. Additionally, misconfigured CORS settings can allow cross-origin requests with Basic Auth, enabling unauthorized origins to receive detailed responses that would otherwise be restricted.

The interaction with other checks in a middleBrick scan is important here. Input Validation findings can amplify Excessive Data Exposure because missing validation may allow injection or malformed requests that trigger verbose errors. Authorization findings related to BOLA or IDOR become more severe when endpoints return full objects, as an attacker can iterate over identifiers and harvest sensitive fields. middleBrick’s OpenAPI/Swagger analysis correlates the spec definition of responses with runtime behavior, detecting cases where the documented schema is less restrictive than what the endpoint actually returns, including across authenticated routes using Basic Auth.

In a middleBrick scan, this combination is flagged under the Data Exposure category, with severity informed by the sensitivity of the returned fields and the presence of persistent credentials. The report will highlight endpoints that return identifiers, internal keys, or error details when called with valid Basic Auth credentials, providing prioritized findings and remediation guidance rather than attempting to fix the service.

Remediation focuses on minimizing data returned to the client and ensuring that authentication does not amplify exposure. This includes returning only necessary fields, avoiding inclusion of sensitive metadata, and ensuring that error messages are generic.

Example of a vulnerable Express endpoint using Basic Auth

const express = require('express');
const app = express();
const auth = require('basic-auth');

const users = [
  { id: 1, username: 'alice', password: '$2a$10$abc123...', email: 'alice@example.com', role: 'admin' },
  { id: 2, username: 'bob', password: '$2a$10$def456...', email: 'bob@example.com', role: 'user' }
];

function verifyUser(credentials) {
  return users.find(u => u.username === credentials.name && u.password === credentials.pass);
}

app.get('/profile', (req, res) => {
  const credentials = auth(req);
  if (!credentials) {
    res.set('WWW-Authenticate', 'Basic realm="example"');
    return res.status(401).send('Authentication required');
  }
  const user = verifyUser(credentials);
  if (!user) {
    return res.status(401).send('Invalid credentials');
  }
  // Vulnerable: returning full user object
  res.json(user);
});

app.listen(3000);

Secured endpoint returning a minimal data set

app.get('/profile', (req, res) => {
  const credentials = auth(req);
  if (!credentials) {
    res.set('WWW-Authenticate', 'Basic realm="example"');
    return res.status(401).send('Authentication required');
  }
  const user = verifyUser(credentials);
  if (!user) {
    return res.status(401).send('Invalid credentials');
  }
  // Secure: returning only required fields
  res.json({
    id: user.id,
    username: user.username,
    email: user.email,
    role: user.role
  });
});

Additional remediation practices include using consistent, non-descriptive error messages to avoid leaking stack traces, validating and sanitizing all inputs to prevent injection that could trigger verbose responses, and ensuring that logging does not capture credentials or sensitive payloads. When integrating with API documentation tools, ensure that response schemas reflect the minimal data structure and do not inadvertently disclose internal fields.

For teams using middleBrick, the CLI can be run as middlebrick scan <url> to identify endpoints with Excessive Data Exposure while using Basic Auth, and the GitHub Action can enforce that new routes do not regress on exposure before merge. The MCP Server allows these checks to be run directly from development environments, integrating security into the coding workflow without requiring changes to how credentials are handled.