Information Disclosure in Express with Bearer Tokens

Information disclosure in Express applications that rely on Bearer tokens occurs when sensitive authentication material or related data is unintentionally exposed to unauthorized parties. Bearer tokens are widely used for stateless authentication in REST APIs, but their effectiveness depends on proper handling at every layer of the application and infrastructure. When an Express API transmits or stores Bearer tokens insecurely, or reflects them inadvertently in responses, logs, or error messages, the confidentiality of the token—and the resources it protects—is compromised.

One common scenario is verbose error handling that includes the Authorization header value in stack traces or JSON error responses. For example, if an Express route does not validate the presence or format of a Bearer token and passes the raw header to downstream services or logging utilities, the token can appear in console output, log files, or crash reports. An attacker who gains access to these artifacts can reuse the token to impersonate the original client.

Another vector involves misconfigured CORS or proxy settings in front of an Express service. If an API responds to preflight requests with overly broad origins or exposes headers such as Authorization to untrusted domains, a malicious site can make authenticated requests on behalf of a victim. Even when tokens are transmitted over HTTPS, insecure defaults or missing HTTP security headers can enable token leakage through referrer URLs or browser-side JavaScript that should not have access to authenticated routes.

Middleware that logs incoming requests is another source of unintentional disclosure. If request logging includes the full Authorization header without redaction, tokens can accumulate in log aggregation systems. These systems may have broader access controls than the application itself, or may be retained for extended periods, increasing the window of exposure. In distributed systems, tokens may also be passed to external APIs via headers like Authorization; if those integrations are not secured to the same standard, the token can be leaked outside the intended trust boundary.

Specification-level issues can also contribute to disclosure. For instance, if an OpenAPI specification incorrectly marks security requirements as optional or omits security schemes for certain paths, clients and generated documentation may fail to indicate that Bearer token protection is required. This can lead to implementations where some routes are inadvertently left unauthenticated, allowing an attacker to observe tokens in transit or infer which endpoints require authentication based on differing behavior.

Server-side session or token storage patterns in Express apps can also leak information through timing differences or error messages. If token validation logic reveals whether a token is malformed versus valid before performing a time-consuming check, an attacker can infer information about token structure. Similarly, if token refresh or introspection endpoints return different error messages for missing versus invalid tokens, these distinctions can be exploited to learn whether a captured token is currently active.

These issues are detectable through coordinated specification and runtime analysis, where definitions in an OpenAPI document are cross-referenced against actual runtime behavior. Such analysis can surface mismatches between documented security requirements and implemented protections, including cases where Bearer token usage is inconsistent across endpoints or where sensitive data appears in output streams that should be sanitized.

Remediation focuses on preventing the presence and visibility of Bearer tokens in logs, errors, and unintended network paths. The following Express patterns demonstrate secure handling of Authorization headers and related data.

1. Redact Authorization headers in logs

Ensure logging middleware never writes the raw Authorization header to output. Use a wrapper that replaces the token with a placeholder.

const morgan = require('morgan');
const tokenRedactionFormatter = (tokens, req, res) =>
  `:method ${tokens.method(:url :url} :status ${tokens.status(req, res)} - ${req.headers.authorization ? 'Authorization: Bearer [redacted]' : 'no auth'}}`;
app.use(morgan(tokenRedactionFormatter));

2. Validate and normalize Authorization header early

Check the presence and format of the Bearer token before proceeding. Return a generic error without revealing token validity details.

const authenticate = (req, res, next) => {
  const header = req.headers.authorization;
  if (!header || !header.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  const token = header.slice(7);
  if (token.trim() === '') {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  // Optionally attach normalized token for downstream use
  req.authToken = token;
  next();
};
app.use(authenticate);

3. Avoid exposing tokens in error responses

Use centralized error handlers that strip sensitive fields, including any accidental echo of Authorization data.

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

4. Enforce HTTPS and secure transport headers

Ensure tokens are only accepted over TLS and that security headers prevent leakage via browser side channels.

const helmet = require('helmet');
app.use(helmet());
app.use((req, res, next) => {
  if (req.headers['x-forwarded-proto'] !== 'https') {
    return res.status(400).json({ error: 'HTTPS required' });
  }
  next();
});

5. Secure CORS configuration

Restrict origins and avoid exposing Authorization to untrusted domains.

const cors = require('cors');
app.use(cors({
  origin: 'https://trusted.example.com',
  methods: ['GET', 'POST'],
  credentials: true
}));

6. Prevent token leakage to external services

When calling downstream APIs, avoid passing Authorization headers unless necessary, and ensure outbound requests do not log the token.

const fetch = require('node-fetch');
const callExternalService = async (internalToken, externalUrl) =>
  fetch(externalUrl, {
    method: 'GET',
    headers: {
      'X-Internal-Token': internalToken
      // Do not forward Authorization: Bearer  unless required
    }
  });

These practices reduce the likelihood of tokens appearing in logs, error payloads, or unintended network paths. They align with secure handling principles where tokens are treated as opaque credentials that must not be reflected in responses or diagnostic output.