Null Pointer Dereference in Express

Null pointer dereference in Express applications typically occurs when request handlers assume properties exist on request objects without validation. This vulnerability manifests in several Express-specific patterns.

The most common scenario involves accessing req.body, req.params, or req.query properties without checking if they exist. For example:

app.post('/api/users/:id', (req, res) => {
  const userId = req.params.id;
  const userData = req.body.user;
  
  // DEREFERENCE WITHOUT VALIDATION
  const email = userData.email.toLowerCase();
  
  res.json({ email });
});

If req.body.user is null or undefined, calling .toLowerCase() throws a TypeError, potentially crashing the application or exposing stack traces to attackers.

Express middleware chains create additional dereference risks. When middleware fails to populate expected properties, downstream handlers may crash:

function authMiddleware(req, res, next) {
  // Missing error handling
  const token = req.headers.authorization.split(' ')[1];
  req.user = verifyToken(token);
  next();
}

app.get('/api/profile', (req, res) => {
  // Assumes req.user exists
  const profile = await db.getUser(req.user.id);
  res.json(profile);
});

If req.headers.authorization is missing or malformed, split() throws, skipping next() and leaving subsequent handlers with undefined data.

Route parameter handling presents another attack surface. Express doesn't validate parameter existence:

app.get('/api/items/:category/:id', (req, res) => {
  const { category, id } = req.params;
  
  // DEREFERENCE WITHOUT VALIDATION
  const items = await db.query(`SELECT * FROM items WHERE category = '${category}' AND id = ${id}`);
  res.json(items);
});

Attackers can trigger null dereferences by omitting parameters or sending malformed requests that bypass route matching.

Body parsing middleware creates similar risks. Without proper validation, handlers assume parsed bodies contain expected structures:

app.post('/api/upload', (req, res) => {
  // Assumes req.file exists
  const filePath = req.file.path;
  const fileSize = fs.statSync(filePath).size;
  
  res.json({ uploaded: true, size: fileSize });
});

If file upload fails or is bypassed, req.file is undefined, causing fs.statSync() to throw.

Detecting null pointer dereferences in Express requires both static analysis and runtime monitoring. The most effective approach combines automated scanning with manual code review.

middleBrick's black-box scanning identifies dereference vulnerabilities by sending malformed requests designed to trigger null property access. The scanner tests:

• Missing body parameters in POST/PUT requests
• Empty query strings in GET requests
• Malformed JSON bodies
• Missing authentication headers
• Invalid route parameters

For example, middleBrick sends requests like:

POST /api/users/123 HTTP/1.1
Content-Type: application/json

{}

This tests whether handlers properly validate req.body.user existence before property access.

Express-specific runtime monitoring involves error tracking middleware:

app.use((err, req, res, next) => {
  if (err instanceof TypeError && err.message.includes('Cannot read property')) {
    console.error('Null pointer dereference detected:', {
      url: req.originalUrl,
      method: req.method,
      headers: req.headers,
      body: req.body
    });
  }
  next(err);
});

This catches dereference errors at runtime, logging sufficient context for remediation.

Static analysis tools can identify risky patterns:

// Risky pattern: property access without validation
const value = obj.property.nested;

Tools like ESLint with custom rules can flag these patterns in Express applications.

middleBrick's OpenAPI analysis cross-references API specifications with runtime behavior, identifying endpoints where specifications suggest required parameters but handlers don't validate their presence.

Express provides several native mechanisms for preventing null pointer dereferences. The most robust approach combines validation middleware with defensive coding patterns.

Express-validator provides declarative validation:

const { body, param, validationResult } = require('express-validator');

app.post('/api/users',
  body('user').exists().withMessage('User data required'),
  body('user.email').isEmail().withMessage('Valid email required'),
  (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).json({ errors: errors.array() });
    }
    
    const { email } = req.body.user;
    // Safe to use email - validation passed
    res.json({ email: email.toLowerCase() });
  }
);

This ensures req.body.user exists before accessing properties.

For middleware chains, use error-handling patterns:

function authMiddleware(req, res, next) {
  try {
    const authHeader = req.headers.authorization;
    if (!authHeader) {
      return res.status(401).json({ error: 'Missing authorization' });
    }
    
    const token = authHeader.split(' ')[1];
    req.user = verifyToken(token);
    next();
  } catch (error) {
    next(new Error('Authentication failed'));
  }
}

app.get('/api/profile', authMiddleware, (req, res) => {
  if (!req.user) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  
  const profile = await db.getUser(req.user.id);
  res.json(profile);
});

Route parameter validation prevents dereference through optional chaining:

app.get('/api/items/:category/:id?', (req, res) => {
  const { category, id } = req.params;
  
  // Optional chaining prevents dereference
  const categoryId = id?.toString();
  
  const items = await db.query(`SELECT * FROM items WHERE category = $1`, [category]);
  res.json(items);
});

Body parsing middleware should include error handling:

app.post('/api/upload', upload.single('file'), (req, res) => {
  if (!req.file) {
    return res.status(400).json({ error: 'File upload required' });
  }
  
  const filePath = req.file.path;
  const fileSize = fs.statSync(filePath).size;
  
  res.json({ uploaded: true, size: fileSize });
});

Express's built-in validation through middleware chains provides the most reliable protection against null pointer dereferences.