Credential Stuffing in Restify (Javascript)

Restify is a Node.js framework optimized for building REST APIs, often used for high-throughput services where performance matters. When handling authentication endpoints in Restify with JavaScript, developers frequently implement login routes using server.post('/login', handler). If this endpoint lacks proper rate limiting or request validation, it becomes a prime target for credential stuffing attacks—where attackers automate login attempts using leaked username-password pairs from data breaches.

The vulnerability arises not from Restify itself, but from common implementation patterns. For example, a basic login handler might look like this:

const restify = require('restify');
const server = restify.createServer();

server.post('/login', (req, res, next) => {
  const { username, password } = req.body;
  // Direct database lookup without throttling
  db.getUserByUsername(username, (err, user) => {
    if (err) return next(err);
    if (!user || user.password !== password) {
      res.send(401, { error: 'Invalid credentials' });
    } else {
      res.send(200, { token: generateToken(user) });
    }
    next();
  });
});

server.listen(3000);

This code exposes the API to credential stuffing because:

• No rate limiting: An attacker can send hundreds of login attempts per second from distributed IPs.
• No account lockout: Failed attempts don’t trigger temporary bans.
• Distinguishable responses: The same 401 response for both 'user not found' and 'wrong password' still allows user enumeration via timing differences or response size in some implementations.
• No CAPTCHA or bot detection: Automated scripts can bypass basic checks.

Restify’s lightweight nature means it doesn’t include built-in throttling or authentication guards—developers must add these layers. Without them, the login endpoint becomes a high-volume attack surface. middleBrick detects this risk during its black-box scan by sending rapid sequences of credential pairs to the /login endpoint and measuring response patterns, flagging missing rate limits as a medium-to-high severity finding under the 'Rate Limiting' and 'Authentication' categories.

To mitigate credential stuffing in a Restify API, implement layered defenses directly in your JavaScript code. Start with rate limiting using the restify-throttle plugin, which integrates cleanly with Restify’s middleware system.

First, install the plugin:

npm install restify-throttle

Then apply it globally or to specific routes. Here’s a secure login handler with per-IP rate limiting (5 attempts per 15 minutes) and generic error messages to prevent user enumeration:

const restify = require('restify');
const throttle = require('restify-throttle');
const server = restify.createServer();

// Global throttle: 5 requests per IP per 15 minutes
server.use(throttle({
  burst: 5,
  rate: 1 / 1800, // 1 request per 30 seconds averaged over burst
  ip: true,
  overrides: {
    '127.0.0.1': { rate: 0, burst: 0 } // disable for localhost if needed
  }
}));

server.post('/login', (req, res, next) => {
  const { username, password } = req.body;

  // Simulate consistent delay to prevent timing attacks
  const start = Date.now();
  db.getUserByUsername(username, (err, user) => {
    const delay = Math.max(0, 100 - (Date.now() - start)); // ensure ~100ms response
    setTimeout(() => {
      if (err) return next(err);

      // Generic response regardless of whether user exists
      const isValid = user && user.password === password;
      if (!isValid) {
        res.send(401, { error: 'Invalid credentials' });
        return next();
      }

      // Proceed with token generation on success
      res.send(200, { token: generateToken(user) });
      next();
    }, delay);
  });
});

server.listen(3000, () => {
  console.log('Server listening at %s', server.url);
});

Additional JavaScript-specific improvements:

• Use bcrypt.compare() instead of direct password comparison to avoid timing leaks.
• Log failed attempts and trigger alerts via middleware (e.g., using winston) when thresholds are approached.
• For stricter control, implement custom middleware that tracks failed logins per username (not just IP) to counteract IP rotation.

middleBrick validates these fixes by rescanning the endpoint and verifying that rate limits are enforced, response timing is consistent, and no user enumeration is possible. The platform reports improvements in the 'Rate Limiting' and 'Authentication' categories, directly supporting compliance with OWASP API Security Top 10 (A3:2019 – Excessive Data Exposure and A2:2019 – Broken Authentication).