Insufficient Logging in Express

Insufficient logging in Express applications creates blind spots that attackers exploit to evade detection and maintain persistence. Express's minimalist architecture, while elegant, can inadvertently enable attackers to operate undetected when logging is improperly configured.

Consider authentication bypass attempts. Without proper logging middleware, repeated failed login attempts go unnoticed. An attacker can brute force API keys or session tokens without triggering alerts. Express's default behavior doesn't log failed authentication attempts unless explicitly configured:

app.post('/login', (req, res) => {
  const { username, password } = req.body;
  User.findOne({ username }, (err, user) => {
    if (!user || !user.comparePassword(password)) {
      // No logging here - attack goes undetected
      return res.status(401).json({ error: 'Invalid credentials' });
    }
    // Successful login - but no logging of success either
    req.session.userId = user.id;
    res.json({ token: createToken(user) });
  });
});

API endpoint enumeration becomes trivial when Express applications lack request logging. Attackers systematically probe endpoints to map the application surface. Without logging, you never know which endpoints were tested or what data was exposed. This is particularly dangerous in Express applications using dynamic routing:

app.use('/api/:version/:resource', (req, res) => {
  const { version, resource } = req.params;
  // Dynamic endpoints - easy to enumerate if not logged
  const handler = getHandler(version, resource);
  if (handler) {
    handler(req, res);
  } else {
    res.status(404).end(); // No logging of 404s
  }
});

Data exfiltration through Express's body parsing capabilities often goes unnoticed. When Express parses JSON bodies without logging the contents, attackers can extract sensitive data through crafted requests. The default body parser doesn't log request payloads:

app.post('/upload', express.json(), (req, res) => {
  const fileData = req.body;
  // File upload endpoint - what if fileData contains PII?
  // No logging of request body means exfiltration is invisible
  processUpload(fileData);
  res.json({ success: true });
});

Rate limiting bypass is another critical failure point. Express applications without request rate logging allow attackers to flood endpoints with requests, potentially causing DoS or overwhelming authentication systems. Without logging request frequencies, you can't distinguish legitimate traffic from attacks:

app.get('/data/:id', (req, res) => {
  const { id } = req.params;
  // No rate limiting or logging - open to abuse
  getData(id, (err, data) => {
    res.json(data);
  });
});

Detecting insufficient logging in Express requires examining both application code and runtime behavior. middleBrick's black-box scanning approach is particularly effective for Express applications since it tests the actual running API without requiring source code access.

middleBrick's logging analysis checks for several Express-specific patterns. It tests whether authentication endpoints properly log both successful and failed attempts. The scanner sends multiple authentication requests with invalid credentials and analyzes the response patterns - a lack of rate limiting or authentication attempt logging is a red flag.

For Express applications using middleware chains, middleBrick verifies that logging middleware is properly positioned. Express executes middleware in the order it's defined, so logging middleware must come before route handlers to capture all requests. The scanner tests this by making requests to various endpoints and checking for consistent logging behavior.

middleBrick's inventory management check is crucial for Express applications. It identifies all exposed endpoints, including those created through dynamic routing or mounted routers. Express's flexible routing system can create endpoints that developers forget to log. The scanner systematically probes the API surface to ensure no endpoints are left unmonitored.

The scanner also tests Express's error handling patterns. Many Express applications use error-handling middleware but fail to log the errors properly. middleBrick sends requests designed to trigger errors and analyzes whether those errors are logged with sufficient detail, including stack traces, request context, and user information where appropriate.

For applications using Express's built-in security middleware like helmet or cors, middleBrick verifies that security events are logged. These middleware components can block requests, but if those blocks aren't logged, you lose visibility into attack attempts.

middleBrick's continuous monitoring feature is particularly valuable for Express applications in production. It can be configured to periodically scan your API endpoints, ensuring that logging coverage remains complete even as the application evolves. This is critical for Express applications that often have rapid development cycles.

Remediating insufficient logging in Express applications requires a comprehensive approach using Express's native features and ecosystem. The first step is implementing proper logging middleware that captures all requests before they reach route handlers.

const express = require('express');
const logger = require('morgan');
const app = express();

// Request logging middleware - captures all requests
app.use(logger(':method :url :status :response-time ms - :res[content-length]'));

// Security event logging
app.use((req, res, next) => {
  res.on('finish', () => {
    if (res.statusCode >= 400) {
      console.log(`SECURITY: ${req.method} ${req.url} returned ${res.statusCode}`);
    }
  });
  next();
});

For authentication logging, Express applications should log both successful and failed attempts with sufficient context. This includes IP addresses, user agents, and timestamps:

app.post('/login', (req, res, next) => {
  const { username, password } = req.body;
  
  User.findOne({ username }, (err, user) => {
    if (err || !user || !user.comparePassword(password)) {
      console.log(`Failed login attempt: ${username} from ${req.ip}`);
      return res.status(401).json({ error: 'Invalid credentials' });
    }
    
    console.log(`Successful login: ${username} from ${req.ip}`);
    req.session.userId = user.id;
    res.json({ token: createToken(user) });
  });
});

Express applications should implement structured logging for better analysis. Using a library like winston allows for JSON-formatted logs that are easier to parse and analyze:

const winston = require('winston');

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  transports: [
    new winston.transports.File({ filename: 'api.log' }),
    new winston.transports.Console()
  ]
});

// Use structured logging throughout your Express app
app.post('/api/data', (req, res) => {
  const { data } = req.body;
  logger.info('Data received', {
    userId: req.user?.id,
    endpoint: req.originalUrl,
    ip: req.ip,
    dataLength: data?.length
  });
  processData(data);
  res.json({ success: true });
});

For Express applications using async/await patterns, proper error handling with logging is essential. The async wrapper pattern ensures that errors are caught and logged:

const asyncHandler = fn => (req, res, next) => {
  Promise.resolve(fn(req, res, next)).catch(next);
};

app.get('/api/resource/:id', asyncHandler(async (req, res) => {
  try {
    const resource = await getResource(req.params.id);
    logger.info('Resource retrieved', {
      resourceId: req.params.id,
      userId: req.user?.id
    });
    res.json(resource);
  } catch (error) {
    logger.error('Resource retrieval failed', {
      resourceId: req.params.id,
      error: error.message,
      stack: error.stack
    });
    throw error;
  }
}));

Rate limiting with logging is another critical Express pattern. Using express-rate-limit with custom logging provides visibility into potential abuse:

const rateLimit = require('express-rate-limit');

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5, // limit each IP to 5 requests per windowMs
  message: 'Too many login attempts',
  standardHeaders: true,
  legacyHeaders: false,
  onLimitReached: (req, res, options) => {
    logger.warn('Rate limit exceeded', {
      ip: req.ip,
      endpoint: req.originalUrl,
      method: req.method
    });
  }
});

app.post('/login', loginLimiter, (req, res) => {
  // Login logic here
});