Protecting APIs from Abuse: Rate Limiting Strategies in Express

Securing a backend service often starts with controlling traffic. The packages express-brute, express-rate-limit, express-slow-down, and rate-limiter-flexible all aim to stop abuse, but they use different methods and have different levels of support. Let's look at how they handle real-world engineering challenges.

🛠️ Maintenance and Project Health

Project health matters because security libraries need updates. If a package is abandoned, it becomes a risk.

express-brute is no longer maintained.

• The repository has not seen significant updates in years.
• Using it introduces potential security vulnerabilities without fixes.

// express-brute: Legacy setup (Not recommended)
const ExpressBrute = require('express-brute');
const store = new ExpressBrute.MemoryStore();
const bruteforce = new ExpressBrute(store);
// ⚠️ Warning: No longer receiving security patches

express-rate-limit is actively maintained.

• It receives regular updates for security and performance.
• Widely adopted in the Express ecosystem.

// express-rate-limit: Active setup
const rateLimit = require('express-rate-limit');
const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100
});
// ✅ Regularly updated and secure

express-slow-down is actively maintained.

• Often updated alongside express-rate-limit.
• Focused specifically on delay tactics.

// express-slow-down: Active setup
const slowDown = require('express-slow-down');
const speedLimiter = slowDown({
  windowMs: 15 * 60 * 1000,
  delayAfter: 100,
  delayMs: 500
});
// ✅ Regularly updated and secure

rate-limiter-flexible is actively maintained.

• Supports many modern stores and frameworks.
• Active community and documentation.

// rate-limiter-flexible: Active setup
const { RateLimiterRedis } = require('rate-limiter-flexible');
const rateLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  points: 10,
  duration: 1
});
// ✅ Regularly updated and secure

⚙️ Basic Configuration and Setup

Setting up limits should be clear. Each package handles configuration differently.

express-brute uses a constructor with store options.

• You define the store first, then the middleware.
• Configuration is tied to the instance creation.

// express-brute: Constructor based
const failCallback = (req, res, next, nextValidRequestDate) => {
  res.status(429).send('Too many requests');
};
const bruteforce = new ExpressBrute(store, {
  failCallback: failCallback,
  minWait: 500,
  maxWait: 1000 * 60 * 60
});
app.post('/login', bruteforce.prevent, loginHandler);

express-rate-limit uses a simple options object.

• Configuration is passed directly to the main function.
• Very readable for standard limits.

// express-rate-limit: Options object
const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
  message: 'Too many requests from this IP'
});
app.use('/api/', limiter);

express-slow-down uses delay-specific options.

• You configure when delays start and how long they last.
• Focuses on time penalties rather than hard blocks.

// express-slow-down: Delay options
const speedLimiter = slowDown({
  windowMs: 15 * 60 * 1000,
  delayAfter: 50,
  delayMs: (hits) => hits * 1000
});
app.use('/api/', speedLimiter);

rate-limiter-flexible uses class instantiation.

• You create a limiter object with strict typing options.
• Requires more setup but allows complex rules.

// rate-limiter-flexible: Class instantiation
const rateLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  keyPrefix: 'middleware',
  points: 10,
  duration: 1,
  blockDuration: 60
});
app.use('/api/', (req, res, next) => {
  rateLimiter.consume(req.ip)
    .then(() => next())
    .catch(() => res.status(429).send('Too Many Requests'));
});

💾 Storage Backends and Scalability

Where you store request counts affects performance and scaling.

express-brute supports Memory and Redis.

• Memory store is for single-instance apps only.
• Redis allows multiple servers to share limit data.

// express-brute: Redis Store
const RedisStore = require('express-brute-redis');
const store = new RedisStore({
  host: '127.0.0.1',
  port: 6379
});
// ⚠️ Limited store options compared to modern tools

express-rate-limit supports Memory, Redis, and Memcached.

• Default is Memory, which resets on restart.
• Redis store is recommended for production clusters.

// express-rate-limit: Redis Store
const RedisStore = require('rate-limit-redis');
const limiter = rateLimit({
  store: new RedisStore({
    sendCommand: (...args) => redisClient.call(...args),
  }),
  windowMs: 15 * 60 * 1000,
  max: 100
});
// ✅ Standard store integrations

express-slow-down shares stores with express-rate-limit.

• Uses the same underlying storage mechanisms.
• Ensures consistency when used together.

// express-slow-down: Redis Store
const RedisStore = require('rate-limit-redis');
const speedLimiter = slowDown({
  store: new RedisStore({
    sendCommand: (...args) => redisClient.call(...args),
  }),
  windowMs: 15 * 60 * 1000
});
// ✅ Consistent storage with rate-limit

rate-limiter-flexible supports many databases.

• Works with Redis, Memcached, MongoDB, Postgres, and more.
• Best choice if you already have a specific database infrastructure.

// rate-limiter-flexible: Mongo Store
const { RateLimiterMongo } = require('rate-limiter-flexible');
const rateLimiter = new RateLimiterMongo({
  storeClient: mongoClient,
  tableName: 'rate_limits',
  points: 10,
  duration: 1
});
// ✅ Wide variety of supported stores

🚦 Response Behavior: Block vs Delay

How the server reacts to too many requests changes the user experience.

express-brute blocks requests after a limit.

• It returns an error immediately.
• Can implement progressive wait times before blocking.

// express-brute: Progressive blocking
const bruteforce = new ExpressBrute(store, {
  minWait: 500,
  maxWait: 1000 * 60,
  failCallback: (req, res) => res.status(429).send('Blocked')
});
// ❌ Hard block after retries exhausted

express-rate-limit blocks requests after a limit.

• Returns HTTP 429 Too Many Requests.
• Simple and effective for hard limits.

// express-rate-limit: Hard block
const limiter = rateLimit({
  max: 5,
  handler: (req, res) => {
    res.status(429).send('Too many requests, please try again later.');
  }
});
// ❌ Hard block immediately after limit

express-slow-down delays responses instead of blocking.

• Requests still succeed but take longer.
• Discourages bots without breaking legitimate users.

// express-slow-down: Delay response
const speedLimiter = slowDown({
  delayAfter: 5,
  delayMs: (hits) => hits * 1000 // 1s, 2s, 3s...
});
// ✅ Slows down traffic instead of dropping it

rate-limiter-flexible allows custom actions.

• You decide what happens in the .catch() block.
• Can block, delay manually, or log and allow.

// rate-limiter-flexible: Custom action
rateLimiter.consume(key)
  .then(() => next())
  .catch((rej) => {
    if (rej.msBeforeNext) {
      res.setHeader('Retry-After', Math.ceil(rej.msBeforeNext / 1000));
    }
    res.status(429).send('Limit exceeded');
  });
// ✅ Fully customizable response logic

🌐 Framework Support and Flexibility

Some tools work only with Express, while others fit anywhere.

express-brute is Express only.

• Middleware is tightly coupled to Express request objects.
• Cannot be used with Koa, Fastify, or NestJS easily.

// express-brute: Express middleware
app.use('/auth', bruteforce.prevent);
// ❌ Tightly coupled to Express

express-rate-limit is Express only.

• Designed specifically for the Express middleware stack.
• Does not work outside the Express ecosystem.

// express-rate-limit: Express middleware
app.use(limiter);
// ❌ Tightly coupled to Express

express-slow-down is Express only.

• Companion to express-rate-limit.
• Shares the same ecosystem limitations.

// express-slow-down: Express middleware
app.use(speedLimiter);
// ❌ Tightly coupled to Express

rate-limiter-flexible works with many frameworks.

• Supports Express, Koa, NestJS, Hapi, and raw Node.js.
• Logic is separated from the framework layer.

// rate-limiter-flexible: Framework agnostic
// Works in Express
app.use((req, res, next) => { /* consume */ });
// Works in Koa
app.use(async (ctx, next) => { /* consume */ });
// ✅ Works across multiple frameworks

📊 Summary: Key Differences

💡 The Big Picture

express-brute is a legacy tool that should be replaced. It served a purpose in the past but lacks modern support. Do not start new projects with it.

express-rate-limit is the go-to for standard Express apps. It is simple, reliable, and solves 90% of use cases with minimal code. Pair it with express-slow-down if you need to throttle traffic before blocking it.

express-slow-down is a specialized tool for DDoS mitigation. It makes attacks expensive for the attacker without cutting off users entirely. It works best as a companion to a hard rate limiter.

rate-limiter-flexible is the power user choice. If you need to share limits across different services, use non-Redis databases, or work outside of Express, this is the right pick. It requires more setup but scales better with complex architectures.

Final Thought: For most teams, start with express-rate-limit. It is the path of least resistance. Move to rate-limiter-flexible only when your architecture outgrows the Express ecosystem or requires specific database integrations.