Time Of Check Time Of Use in Express

Time Of Check Time Of Use (TOCTOU) in Express applications typically occurs when an application verifies a condition, then performs an action based on that verification, but the underlying state changes between those two operations. Express's asynchronous nature and middleware architecture create several specific TOCTOU vulnerabilities.

A classic Express TOCTOU scenario involves file operations. Consider this vulnerable pattern:

app.get('/download/:filename', (req, res) => {
  const filePath = path.join(__dirname, 'uploads', req.params.filename);
  
  // Time Of Check: verify file exists
  if (fs.existsSync(filePath)) {
    // Time Of Use: read file contents
    const data = fs.readFileSync(filePath);
    res.send(data);
  } else {
    res.status(404).send('File not found');
  }
});

Between the fs.existsSync() check and the fs.readFileSync() operation, an attacker could delete the file, causing the application to crash or leak sensitive information through error messages.

Database operations in Express create similar TOCTOU windows. In a user deletion endpoint:

app.delete('/users/:id', async (req, res) => {
  const userId = req.params.id;
  
  // Time Of Check: verify user exists
  const user = await User.findById(userId);
  if (!user) {
    return res.status(404).send('User not found');
  }
  
  // Time Of Use: delete user
  await User.deleteOne({ _id: userId });
  res.send('User deleted');
});

An attacker could exploit the gap between the find and delete operations, potentially causing race conditions in audit logging or permission systems.

Middleware-based TOCTOU is particularly insidious in Express. Consider authentication middleware:

function checkAuth(req, res, next) {
  // Time Of Check: verify session exists
  if (req.session && req.session.userId) {
    next();
  } else {
    res.status(401).send('Unauthorized');
  }
}

app.get('/admin', checkAuth, (req, res) => {
  // Time Of Use: perform admin action
  res.send('Admin dashboard');
});

If session invalidation happens asynchronously after the check but before the admin action, users might retain access briefly after logout.

File upload TOCTOU in Express often involves path traversal combined with timing attacks:

app.post('/upload', upload.single('file'), (req, res) => {
  const filePath = path.join(__dirname, 'uploads', req.file.originalname);
  
  // Time Of Check: verify path is within uploads directory
  if (!path.normalize(filePath).startsWith(__dirname + '/uploads')) {
    return res.status(400).send('Invalid path');
  }
  
  // Time Of Use: move file to final destination
  fs.rename(req.file.path, filePath, (err) => {
    if (err) throw err;
    res.send('File uploaded');
  });
});

The path normalization check could pass, but the file could be moved outside the intended directory before the rename operation completes.

Detecting TOCTOU in Express requires both static analysis and runtime monitoring. Static analysis tools can identify vulnerable patterns, but runtime detection catches the actual race conditions.

middleBrick's Express-specific scanning identifies TOCTOU vulnerabilities by analyzing your API endpoints and their execution patterns. The scanner examines:

• Middleware chains for authentication and authorization gaps
• File operation patterns that separate check and use operations
• Database query sequences with verification steps
• Session handling and timeout configurations
• Rate limiting implementations that might create TOCTOU windows

middleBrick runs 12 parallel security checks on your Express endpoints, including authentication bypass attempts and race condition simulations. For TOCTOU specifically, it tests:

middlebrick scan https://yourapi.com --checks=authentication,bolaidor,rate-limiting

The scanner attempts to trigger TOCTOU conditions by rapidly alternating requests, simulating concurrent access patterns that expose timing gaps.

Manual detection in Express involves examining your route handlers for the classic check-then-use pattern. Look for:

// Vulnerable pattern to search for:
if (condition) {
  // some operation
}

// Instead use atomic operations:
const result = await atomicOperation();
if (result) {
  // handle success
}

Express middleware order is critical for TOCTOU detection. Middleware that performs checks should be designed to fail fast and prevent further processing if conditions aren't met atomically.

Logging and monitoring in Express can help detect TOCTOU attempts. Implement structured logging around sensitive operations:

app.use(morgan(':method :url :status :response-time ms :user-agent'));

app.post('/sensitive', async (req, res) => {
  const start = Date.now();
  try {
    const result = await sensitiveOperation(req.body);
    const duration = Date.now() - start;
    console.log(`Sensitive operation completed in ${duration}ms`);
    res.json(result);
  } catch (err) {
    console.error('Sensitive operation failed:', err.message);
    res.status(500).send('Internal error');
  }
});

Monitoring tools can alert on unusual patterns like rapid repeated failures followed by successes, which might indicate TOCTOU exploitation attempts.

Express provides several patterns for eliminating TOCTOU vulnerabilities. The key principle is making check and use operations atomic, or eliminating the check entirely when possible.

For file operations, use atomic file system methods instead of separate check and use:

const fs = require('fs').promises;

app.get('/download/:filename', async (req, res) => {
  const filePath = path.join(__dirname, 'uploads', req.params.filename);
  
  try {
    // Atomic operation: readFile throws if file doesn't exist
    const data = await fs.readFile(filePath);
    res.send(data);
  } catch (err) {
    if (err.code === 'ENOENT') {
      res.status(404).send('File not found');
    } else {
      res.status(500).send('Server error');
    }
  }
});

This eliminates the TOCTOU window by combining check and use into a single atomic operation.

For database operations, use transactions or atomic update methods:

app.delete('/users/:id', async (req, res) => {
  const userId = req.params.id;
  
  try {
    // Atomic operation using transactions
    const session = await mongoose.startSession();
    await session.withTransaction(async () => {
      const user = await User.findById(userId).session(session);
      if (!user) {
        throw new Error('User not found');
      }
      await User.deleteOne({ _id: userId }).session(session);
    });
    
    await session.commitTransaction();
    res.send('User deleted');
  } catch (err) {
    res.status(404).send(err.message);
  }
});

Transactions ensure that the verification and deletion happen atomically within the same database session.

Express middleware can be restructured to avoid TOCTOU in authentication:

function atomicAuth(req, res, next) {
  // Single atomic operation: verify and attach user
  User.findById(req.session.userId)
    .then(user => {
      if (!user) {
        return res.status(401).send('Unauthorized');
      }
      req.user = user;
      next();
    })
    .catch(err => {
      res.status(500).send('Authentication error');
    });
}

app.get('/admin', atomicAuth, (req, res) => {
  // req.user is guaranteed to be valid
  res.send('Admin dashboard');
});

This pattern ensures authentication is verified and user data is attached in a single operation.

For rate limiting in Express, use atomic increment operations:

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

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100,
  keyGenerator: req => req.ip,
  // Store rate limit data in Redis for atomic operations
  store: new RedisStore({ client: redisClient })
});

app.use(limiter);

app.post('/api/endpoint', (req, res) => {
  // Rate limiting is handled atomically by middleware
  res.json({ success: true });
});

Redis-based rate limiting ensures atomic increment operations across distributed Express instances.

Input validation should be performed atomically with business logic:

app.post('/create', async (req, res) => {
  const { name, email } = req.body;
  
  try {
    // Atomic validation and creation
    const user = new User({ name, email });
    await user.validate();
    await user.save();
    res.status(201).json(user);
  } catch (err) {
    res.status(400).json({ error: err.message });
  }
});

This pattern validates and persists data in a single operation, eliminating TOCTOU windows in validation logic.