Memory Leak in Express

Memory leaks in Express applications often stem from improper handling of request lifecycles, middleware chains, and event listeners. Express's asynchronous nature and middleware stack create multiple opportunities for memory to accumulate unnoticed.

One common pattern occurs with middleware that attaches data to the request object without proper cleanup. Consider this problematic middleware:

app.use((req, res, next) => {
  req.user = findUserFromToken(req.headers.authorization);
  next();
});

If findUserFromToken creates objects that aren't properly garbage collected, each request adds to memory pressure. The issue compounds when this middleware is used across many routes.

Event listener leaks are particularly insidious in Express. A classic example:

app.get('/stream', (req, res) => {
  const interval = setInterval(() => {
    res.write(`data: ${Date.now()}

`);
  }, 1000);
  
  req.on('close', () => clearInterval(interval));
});

If the close event handler is missing or fails, the interval continues indefinitely, holding references to the response object and preventing garbage collection.

Express's body parsing middleware can also contribute to memory issues. Without proper limits:

app.use(express.json());

A malicious client can send increasingly large payloads, exhausting available memory. The default behavior allows unlimited body sizes, making this a common vulnerability.

Another Express-specific leak pattern involves improper handling of file uploads:

app.post('/upload', (req, res) => {
  const files = [];
  
  req.on('data', chunk => {
    files.push(chunk); // accumulates without bound
  });
  
  req.on('end', () => {
    const buffer = Buffer.concat(files);
    // process buffer
  });
});

Without size limits or backpressure handling, this can quickly consume all available memory.

Detecting memory leaks in Express requires monitoring both application behavior and system resources. The Node.js --inspect flag enables Chrome DevTools profiling:

node --inspect server.js

Once connected, use the Memory tab to take heap snapshots before and after load testing. Compare snapshots to identify objects that persist unexpectedly.

For Express-specific monitoring, middleware can track request lifecycle metrics:

function memoryMonitor(req, res, next) {
  const start = process.memoryUsage().heapUsed;
  const end = Date.now();
  
  res.on('finish', () => {
    const duration = Date.now() - end;
    const memoryUsed = process.memoryUsage().heapUsed - start;
    console.log(`${req.method} ${req.url} - ${duration}ms - ${memoryUsed} bytes`);
  });
  
  next();
}

middleBrick's scanning approach complements these manual techniques by testing the unauthenticated attack surface. It specifically checks for:

• Missing rate limiting that could enable memory exhaustion attacks
• Unsafe consumption patterns in request handlers
• Property authorization issues that might allow unauthorized memory access
• Input validation failures that permit oversized payloads

The scanner runs 12 parallel security checks in 5-15 seconds, testing for memory-related vulnerabilities without requiring credentials or configuration.

Real-time monitoring with tools like pm2 provides additional visibility:

pm2 start server.js --name express-app --watch --log-date-format "YYYY-MM-DD HH:mm Z"

Combined with custom metrics, you can track memory trends and identify leaks before they impact production.

Express provides several native mechanisms for preventing memory leaks. The most effective approach combines proper middleware configuration with defensive coding patterns.

Start with body size limits:

app.use(express.json({ limit: '10mb' }));
app.use(express.urlencoded({ limit: '10mb', extended: true }));

This prevents oversized payloads from consuming excessive memory. For file uploads, use multer with explicit limits:

const upload = multer({
  limits: { fileSize: 10 * 1024 * 1024 }, // 10MB
  storage: multer.memoryStorage()
});

Memory storage is preferable to disk storage for small files, as it allows proper cleanup and avoids file descriptor leaks.

Implement proper error handling to prevent hanging requests:

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

This ensures that errors don't leave requests in limbo, holding resources indefinitely.

For streaming endpoints, always implement proper cleanup:

app.get('/events', (req, res) => {
  const interval = setInterval(() => {
    if (res.writableEnded) {
      clearInterval(interval);
      return;
    }
    res.write(`data: ${Date.now()}

`);
  }, 1000);
  
  res.on('close', () => clearInterval(interval));
  res.on('finish', () => clearInterval(interval));
});

Rate limiting is critical for preventing memory exhaustion attacks:

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

const apiLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100, // limit each IP to 100 requests per windowMs
  message: 'Too many requests from this IP'
});

app.use('/api/', apiLimiter);

For applications using database connections, ensure proper connection pooling and cleanup:

const pool = require('pg').Pool;

const db = new pool({
  max: 10, // limit concurrent connections
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000
});

This prevents connection leaks that can indirectly cause memory pressure through growing connection pools.