express-brute vs express-limiter vs express-rate-limit vs express-slow-down vs rate-limiter-flexible
Express.js 应用中的速率限制与暴力破解防护方案对比
搜索包...
express-bruteexpress-limiterexpress-rate-limitexpress-slow-downrate-limiter-flexible类似的npm包:
Express.js 应用中的速率限制与暴力破解防护方案对比
express-brute、express-limiter、express-rate-limit、express-slow-down 和 rate-limiter-flexible 都是用于保护 Node.js Express 应用免受暴力破解、API 滥用和 DDoS 攻击的中间件。它们通过限制特定 IP 或用户在一定时间内的请求频率来工作，但实现机制、存储后端支持和灵活性各不相同。express-rate-limit 是目前最流行且维护活跃的基础限流方案；rate-limiter-flexible 提供了最强大的跨框架支持和细粒度控制；express-brute 专注于暴力破解防护但已停止维护；express-limiter 是较早期的中间件实现；而 express-slow-down 则采用渐进式延迟策略而非直接拒绝请求。
npm下载趋势
3 年
GitHub Stars 排名
统计详情
Express.js 速率限制中间件深度对比：架构、性能与适用场景
在构建生产级 Express 应用时，保护 API 免受滥用和暴力破解是基本安全要求。本文深入对比五个主流限流中间件，从架构设计、存储支持、配置灵活性到实际代码实现，帮助你在技术选型时做出明智决策。
🛡️ 核心设计理念：直接拒绝 vs 渐进延迟 vs 暴力破解防护
不同包对"如何处理超限请求"有不同哲学。
express-rate-limit 采用标准的令牌桶或固定窗口算法，超限后直接返回 429 状态码。
// express-rate-limit: 直接拒绝超限请求
import rateLimit from 'express-rate-limit';
const limiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 分钟
max: 100, // 每个 IP 最多 100 个请求
message: '请求过多，请稍后再试'
});
app.use('/api/', limiter);
express-slow-down 不直接拒绝，而是随着请求频率增加逐渐延长响应时间。
// express-slow-down: 渐进式延迟
import slowDown from 'express-slow-down';
const speedLimiter = slowDown({
windowMs: 15 * 60 * 1000,
delayAfter: 50, // 50 个请求后开始延迟
delayMs: (hits) => Math.min(hits * 100, 60000) // 每次增加 100ms，最多 60 秒
});
app.use('/api/', speedLimiter);
express-brute 专为登录等敏感端点设计，使用指数退避算法防止暴力破解。
// express-brute: 指数退避防护
import ExpressBrute from 'express-brute';
import MemStore from 'express-brute-mem-store';
const store = new MemStore();
const brute = new ExpressBrute(store);
app.post('/login', brute.prevent, (req, res) => {
// 登录逻辑
res.send('登录成功');
});
express-limiter 提供基础的 Redis 驱动限流，配置相对简单直接。
// express-limiter: Redis 基础限流
import limiter from 'express-limiter';
limiter(app, {
lookup: 'connection.remoteAddress',
total: 100,
expire: 1000 * 60 * 60,
redis: redisClient
});
rate-limiter-flexible 提供最细粒度的控制，支持按用户、IP、端点等多维度组合策略。
// rate-limiter-flexible: 细粒度策略
import { RateLimiterRedis } from 'rate-limiter-flexible';
const rateLimiter = new RateLimiterRedis({
storeClient: redisClient,
keyPrefix: 'middleware',
points: 10,
duration: 1
});
app.use('/api/', (req, res, next) => {
rateLimiter.consume(req.ip)
.then(() => next())
.catch(() => res.status(429).send('Too Many Requests'));
});
💾 存储后端支持：内存 vs Redis vs 多后端
存储选择直接影响限流在集群环境下的有效性。
| 包名 | 内存存储 | Redis | Memcached | 数据库 | 其他 |
|---|---|---|---|---|---|
express-brute | ✅ | ✅ (需额外包) | ❌ | ❌ | MongoDB (需额外包) |
express-limiter | ❌ | ✅ | ❌ | ❌ | ❌ |
express-rate-limit | ✅ | ✅ | ❌ | ❌ | 自定义存储 |
express-slow-down | ✅ | ✅ | ❌ | ❌ | 依赖 express-rate-limit 存储 |
rate-limiter-flexible | ✅ | ✅ | ✅ | ✅ | 15+ 种存储 |
express-rate-limit 内置内存存储，也支持 Redis 通过 rate-limit-redis 包。
// express-rate-limit: Redis 存储配置
import RedisStore from 'rate-limit-redis';
import rateLimit from 'express-rate-limit';
const limiter = rateLimit({
store: new RedisStore({
sendCommand: (...args) => redisClient.call(...args),
}),
windowMs: 15 * 60 * 1000,
max: 100
});
rate-limiter-flexible 支持最广泛的存储后端，包括 Redis、Memcached、MySQL、PostgreSQL、MongoDB 等。
// rate-limiter-flexible: Memcached 存储
import { RateLimiterMemcached } from 'rate-limiter-flexible';
const rateLimiter = new RateLimiterMemcached({
storeClient: memcachedClient,
points: 10,
duration: 1
});
express-brute 需要为不同存储安装额外的 store 包。
// express-brute: MongoDB 存储
import ExpressBrute from 'express-brute';
import MongoDBStore from 'express-brute-mongodb-store';
const store = new MongoDBStore(mongoConnection);
const brute = new ExpressBrute(store);
🔑 键控策略：按 IP vs 按用户 vs 自定义
如何识别"谁"在发起请求决定了限流的精确度。
express-rate-limit 默认按 IP，但支持自定义键生成函数。
// express-rate-limit: 自定义键控
const limiter = rateLimit({
keyGenerator: (req) => {
return req.user ? req.user.id : req.ip;
},
max: 100
});
express-limiter 通过 lookup 配置指定键来源。
// express-limiter: 多键控支持
limiter(app, {
lookup: ['connection.remoteAddress', 'user.id'],
total: 100,
expire: 3600000
});
rate-limiter-flexible 允许在 consume 时动态指定键，最灵活。
// rate-limiter-flexible: 动态键控
app.post('/api/action', async (req, res) => {
const key = req.user ? `user:${req.user.id}` : `ip:${req.ip}`;
try {
await rateLimiter.consume(key);
res.send('操作成功');
} catch (rejRes) {
res.status(429).send('操作过于频繁');
}
});
express-brute 默认按 IP，可通过中间件参数覆盖。
// express-brute: 按用户限流
app.post('/login', brute.prevent, (req, res, next) => {
// 验证逻辑
if (valid) {
brute.reset(req, next); // 成功后重置计数
}
});
express-slow-down 继承 express-rate-limit 的键控逻辑。
// express-slow-down: 与 rate-limit 相同键控
const speedLimiter = slowDown({
keyGenerator: (req) => req.user ? req.user.id : req.ip,
delayAfter: 50,
delayMs: 500
});
⚙️ 配置灵活性与高级功能
rate-limiter-flexible 支持最复杂场景，如不同端点不同限制、用户等级差异化限流。
// rate-limiter-flexible: 多级限流策略
const regularLimiter = new RateLimiterRedis({ points: 10, duration: 1 });
const premiumLimiter = new RateLimiterRedis({ points: 100, duration: 1 });
app.use('/api/', (req, res, next) => {
const limiter = req.user?.isPremium ? premiumLimiter : regularLimiter;
limiter.consume(req.ip).then(() => next()).catch(() => res.status(429).send());
});
express-rate-limit 支持请求头返回限流信息，便于客户端调整。
// express-rate-limit: 返回限流头
const limiter = rateLimit({
standardHeaders: true, // 返回 RateLimit-* 头
legacyHeaders: false,
max: 100
});
express-slow-down 可配置延迟计算函数，实现非线性惩罚。
// express-slow-down: 非线性延迟
const speedLimiter = slowDown({
delayMs: (hits) => Math.pow(hits, 2) * 100 // 指数增长延迟
});
express-brute 支持请求成功后自动重置计数，适合登录场景。
// express-brute: 成功重置
app.post('/login', brute.prevent, (req, res) => {
authenticate(req.body, (err, user) => {
if (user) {
brute.reset(req); // 登录成功重置尝试次数
res.send('欢迎');
}
});
});
express-limiter 配置相对固定，适合简单场景。
// express-limiter: 基础配置
limiter(app, {
total: 100,
expire: 3600000,
lookup: 'connection.remoteAddress'
});
⚠️ 维护状态与生产建议
重要警告：express-brute 已不再积极维护，最后更新距今较久。虽然功能稳定，但存在潜在安全风险，新项目中应避免使用。
express-limiter 维护频率较低，功能基础，适合简单 Redis 限流需求。
express-rate-limit 是目前 Express 生态中最活跃维护的限流包，社区支持好，文档完善。
express-slow-down 由 express-rate-limit 同一作者维护，两者配合使用效果最佳。
rate-limiter-flexible 维护活跃，功能最强大，适合复杂企业级应用，但学习曲线稍陡。
📊 功能对比总结
| 特性 | express-brute | express-limiter | express-rate-limit | express-slow-down | rate-limiter-flexible |
|---|---|---|---|---|---|
| 维护状态 | ⚠️ 停止维护 | 🟡 低频维护 | 🟢 活跃维护 | 🟢 活跃维护 | 🟢 活跃维护 |
| 存储支持 | 有限 | Redis 仅 | 内存 + Redis | 内存 + Redis | 15+ 种后端 |
| 配置灵活性 | 中 | 低 | 高 | 高 | 极高 |
| 跨框架支持 | Express 仅 | Express 仅 | Express 仅 | Express 仅 | 多框架支持 |
| 暴力破解防护 | ✅ 专为设计 | ❌ | ❌ | ❌ | ✅ 可配置 |
| 渐进延迟 | ❌ | ❌ | ❌ | ✅ 核心功能 | ✅ 可配置 |
| 学习曲线 | 低 | 低 | 低 | 低 | 中 |
💡 架构选型建议
场景 1：标准 REST API 限流
推荐：express-rate-limit + Redis
大多数 API 只需要基础的请求频率限制，express-rate-limit 配置简单，社区支持好，足够满足需求。
import rateLimit from 'express-rate-limit';
import RedisStore from 'rate-limit-redis';
const apiLimiter = rateLimit({
store: new RedisStore({ sendCommand: (...args) => redis.call(...args) }),
windowMs: 15 * 60 * 1000,
max: 100,
standardHeaders: true
});
app.use('/api/', apiLimiter);
场景 2：登录端点暴力破解防护
推荐：rate-limiter-flexible（新项目）或 express-brute（旧项目维护）
登录端点需要更严格的防护和指数退避策略。
import { RateLimiterRedis } from 'rate-limiter-flexible';
const loginLimiter = new RateLimiterRedis({
storeClient: redisClient,
keyPrefix: 'login',
points: 5, // 5 次尝试
duration: 60 * 15 // 15 分钟内
});
app.post('/login', async (req, res) => {
try {
await loginLimiter.consume(req.ip);
// 验证逻辑
} catch (rejRes) {
res.status(429).send('尝试次数过多');
}
});
场景 3：微服务架构多框架支持
推荐：rate-limiter-flexible
如果你的应用不仅使用 Express，还涉及 Koa、Fastify 或其他框架，统一使用 rate-limiter-flexible 可以保持限流策略一致。
场景 4：需要保持服务可用性但减缓滥用
推荐：express-rate-limit + express-slow-down 组合
先使用 express-slow-down 减缓频繁请求者，达到硬性限制后再用 express-rate-limit 拒绝。
import slowDown from 'express-slow-down';
import rateLimit from 'express-rate-limit';
const speedLimiter = slowDown({
windowMs: 15 * 60 * 1000,
delayAfter: 50,
delayMs: 500
});
const rateLimiter = rateLimit({
windowMs: 15 * 60 * 1000,
max: 100
});
app.use('/api/', speedLimiter, rateLimiter);
场景 5：多租户 SaaS 应用差异化限流
推荐：rate-limiter-flexible
需要根据用户订阅等级动态调整限流策略。
const limiters = {
free: new RateLimiterRedis({ points: 10, duration: 1 }),
pro: new RateLimiterRedis({ points: 100, duration: 1 }),
enterprise: new RateLimiterRedis({ points: 1000, duration: 1 })
};
app.use('/api/', (req, res, next) => {
const tier = req.user?.subscription || 'free';
limiters[tier].consume(req.user.id)
.then(() => next())
.catch(() => res.status(429).send('超出配额'));
});
🎯 最终建议
对于新项目，优先选择 express-rate-limit（简单场景）或 rate-limiter-flexible（复杂场景）。两者维护活跃，文档完善，社区支持好。
对于旧项目维护，如果已使用 express-brute 或 express-limiter 且运行稳定，可暂时保留，但建议制定迁移计划。
express-slow-down 是很好的补充工具，与 express-rate-limit 配合使用可提供更友好的限流体验。
记住：限流只是安全策略的一环，应结合认证、授权、输入验证等措施构建完整的防护体系。
如何选择: express-brute vs express-limiter vs express-rate-limit vs express-slow-down vs rate-limiter-flexible
- express-brute:
仅建议在维护旧项目时使用，该包已不再积极维护。它专为防止暴力破解设计，支持指数退避策略，但缺乏现代存储后端支持。如果是新项目，请避免使用并考虑迁移到
rate-limiter-flexible。 - express-limiter:
适用于需要简单 Redis 集成的传统 Express 项目。它的配置相对直接，但功能较为基础，缺乏灵活的键控策略。如果你的项目已经依赖它且运行稳定，可以继续使用，但新项目建议评估更现代的替代方案。
- express-rate-limit:
选择它如果你需要简单、轻量且广泛采用的 Express 专用限流中间件。它支持内存和 Redis 存储，配置简单，适合大多数标准 API 限流场景。社区活跃，文档完善，是 Express 生态中的默认选择。
- express-slow-down:
选择它当你希望在不直接拒绝请求的情况下减缓恶意流量。它通过增加响应延迟来惩罚频繁请求者，适合需要保持服务可用性但希望 discouraging 滥用的场景。通常与
express-rate-limit配合使用。 - rate-limiter-flexible:
选择它如果你需要跨框架支持（不仅限于 Express）、细粒度的限流策略或多种存储后端（Redis、Memcached、数据库等）。它提供最灵活的配置选项，适合复杂的企业级应用和微服务架构。
热门对比
express-brute
express-limiter
express-rate-limit
express-slow-down
rate-limiter-flexible
express-brute的README
express-brute
A brute-force protection middleware for express routes that rate-limits incoming requests, increasing the delay with each request in a fibonacci-like sequence.
Installation
via npm:
$ npm install express-brute
A Simple Example
var ExpressBrute = require('express-brute');
var store = new ExpressBrute.MemoryStore(); // stores state locally, don't use this in production
var bruteforce = new ExpressBrute(store);
app.post('/auth',
bruteforce.prevent, // error 429 if we hit this route too often
function (req, res, next) {
res.send('Success!');
}
);
Classes
ExpressBrute(store, options)
storeAn instance ofExpressBrute.MemoryStoreor some other ExpressBrute store (see a list of known stores below).optionsfreeRetriesThe number of retires the user has before they need to start waiting (default: 2)minWaitThe initial wait time (in milliseconds) after the user runs out of retries (default: 500 milliseconds)maxWaitThe maximum amount of time (in milliseconds) between requests the user needs to wait (default: 15 minutes). The wait for a given request is determined by adding the time the user needed to wait for the previous two requests.lifetimeThe length of time (in seconds since the last request) to remember the number of requests that have been made by an IP. By default it will be set tomaxWait * the number of attempts before you hit maxWaitto discourage simply waiting for the lifetime to expire before resuming an attack. With default values this is about 6 hours.failCallbackGets called with (req,resp,next,nextValidRequestDate) when a request is rejected (default: ExpressBrute.FailForbidden)attachResetToRequestSpecify whether or not a simplified reset method should be attached atreq.brute.reset. The simplified method takes only a callback, and resets allExpressBrutemiddleware that was called on the current request. If multiple instances ofExpressBrutehave middleware on the same request, only those withattachResetToRequestset to true will be reset (default: true)refreshTimeoutOnRequestDefines whether thelifetimecounts from the time of the last request that ExpressBrute didn't prevent for a given IP (true) or from of that IP's first request (false). Useful for allowing limits over fixed periods of time, for example: a limited number of requests per day. (Default: true). More infohandleStoreErrorGets called whenever an error occurs with the persistent store from which ExpressBrute cannot recover. It is passed an object containing the propertiesmessage(a description of the message),parent(the error raised by the session store), and [key,ip] or [req,res,next] depending on whether or the error occurs duringresetor in the middleware itself.
ExpressBrute.MemoryStore()
An in-memory store for persisting request counts. Don't use this in production, instead choose one of the more robust store implementations listed below.
ExpressBrute Instance Methods
prevent(req, res, next)Middleware that will bounce requests that happen faster than the current wait time by callingfailCallback. Equivilent togetMiddleware(null)getMiddleware(options)Generates middleware that will bounce requests with the samekeyand IP address that happen faster than the current wait time by callingfailCallback. Also attaches a function atreq.brute.resetthat can be called to reset the counter for the current ip and key. This functions as theresetinstance method, but without the need to explicitly pass theipandkeyparamterskeycan be a string or alternatively it can be afunction(req, res, next)that or callsnext, passing a string as the first parameter.failCallbackAllows you to override the value offailCallbackfor this middlewareignoreIPDisregard IP address when matching requests if set totrue. Defaults tofalse.
reset(ip, key, next)Resets the wait time between requests back to its initial value. You can passnullforkeyif you want to reset a request protected byprotect.
Built-in Failure Callbacks
There are some built-in callbacks that come with BruteExpress that handle some common use cases.
ExpressBrute.FailTooManyRquestsTerminates the request and responses with a 429 (Too Many Requests) error that has aRetry-Afterheader and a JSON error message.ExpressBrute.FailForbiddenTerminates the request and responds with a 403 (Forbidden) error that has aRetry-Afterheader and a JSON error message. This is provided for compatibility with ExpressBrute versions prior to v0.5.0, for new usersFailTooManyRequestsis the preferred behavior.ExpressBrute.FailMarkSets res.nextValidRequestDate, the Retry-After header and the res.status=429, then calls next() to pass the request on to the appropriate routes.
ExpressBrute stores
There are a number adapters that have been written to allow ExpressBrute to be used with different persistent storage implementations, some of the ones I know about include:
If you write your own store and want me to add it to the list, just drop me an email or create an issue.
A More Complex Example
require('connect-flash');
var ExpressBrute = require('express-brute'),
MemcachedStore = require('express-brute-memcached'),
moment = require('moment'),
store;
if (config.environment == 'development'){
store = new ExpressBrute.MemoryStore(); // stores state locally, don't use this in production
} else {
// stores state with memcached
store = new MemcachedStore(['127.0.0.1'], {
prefix: 'NoConflicts'
});
}
var failCallback = function (req, res, next, nextValidRequestDate) {
req.flash('error', "You've made too many failed attempts in a short period of time, please try again "+moment(nextValidRequestDate).fromNow());
res.redirect('/login'); // brute force protection triggered, send them back to the login page
};
var handleStoreError = handleStoreError: function (error) {
log.error(error); // log this error so we can figure out what went wrong
// cause node to exit, hopefully restarting the process fixes the problem
throw {
message: error.message,
parent: error.parent
};
}
// Start slowing requests after 5 failed attempts to do something for the same user
var userBruteforce = new ExpressBrute(store, {
freeRetries: 5,
minWait: 5*60*1000, // 5 minutes
maxWait: 60*60*1000, // 1 hour,
failCallback: failCallback,
handleStoreError: handleStoreError
}
});
// No more than 1000 login attempts per day per IP
var globalBruteforce = new ExpressBrute(store, {
freeRetries: 1000,
attachResetToRequest: false,
refreshTimeoutOnRequest: false,
minWait: 25*60*60*1000, // 1 day 1 hour (should never reach this wait time)
maxWait: 25*60*60*1000, // 1 day 1 hour (should never reach this wait time)
lifetime: 24*60*60, // 1 day (seconds not milliseconds)
failCallback: failCallback,
handleStoreError: handleStoreError
});
app.set('trust proxy', 1); // Don't set to "true", it's not secure. Make sure it matches your environment
app.post('/auth',
globalBruteforce.prevent,
userBruteforce.getMiddleware({
key: function(req, res, next) {
// prevent too many attempts for the same username
next(req.body.username);
}
}),
function (req, res, next) {
if (User.isValidLogin(req.body.username, req.body.password)) { // omitted for the sake of conciseness
// reset the failure counter so next time they log in they get 5 tries again before the delays kick in
req.brute.reset(function () {
res.redirect('/'); // logged in, send them to the home page
});
} else {
res.flash('error', "Invalid username or password")
res.redirect('/login'); // bad username/password, send them back to the login page
}
}
);
Changelog
v1.0.1
- BUG: Fixed an edge case where freeretries weren't being respected if app servers had slightly different times
v1.0.0
- NEW: Updated to use
Express4.x as a peer dependency. - REMOVED:
proxyDepthoption onExpressBrutehas been removed. Useapp.set('trust proxy', x)from Express 4 instead. More Info - REMOVED:
getIPFromRequest(req)has been removed from instances, usereq.ipinstead.
v0.6.0
- NEW: Added new ignoreIP option. (Thanks Magnitus-!)
- CHANGED:
.resetcallbacks are now always called asyncronously, regardless of the implementation of the store (particularly effectsMemoryStore). - CHANGED: Unit tests have been converted from Jasmine to Mocha/Chai/Sinon
- BUG: Fixed a crash when .reset was called without a callback function
v0.5.3
- NEW: Added the
handleStoreErroroption to allow more customizable handling of errors that are thrown by the persistent store. Default behavior is to throw the errors as an exception - there is nothing ExpressBrute can do to recover. - CHANGED: Errors thrown as a result of errors raised by the store now include the store's error as well, for debugging purposes.
v0.5.2
- CHANGED: Stopped using res.send(status, body), as it is deprecated in express 4.x. Instead call res.status and res.send separately (Thanks marinewater!)
v0.5.1
- BUG: When setting proxyDepth to 1, ips is never populated with proxied X-Forwarded-For IP.
v0.5.0
- NEW: Added an additional
FailTooManyRequestsfailure callback, that returns a 429 (TooManyRequests) error instead of 403 (Forbidden). This is a more accurate error status code. - NEW: All the built in failure callbacks now set the "Retry-After" header to the number of seconds until it is safe to try again. Per RFC6585
- NEW: Documentation updated to list some known store implementations.
- CHANGED: Default failure callback is now
FailTooManyRequests.FailForbiddenremains an option for backwards compatiblity. - CHANGED: ExpressBrute.MemcachedStore is no longer included by default, and is now available as a separate module (because there are multiple store options it doesn't really make sense to include one by default).
- CHANGED:
FailMarkno longer sets returns 403 Forbidden, instead does 429 TooManyRequets.
v0.4.2
- BUG: In some cases when no callbacks were supplied memcached would drop the request. Ensure that memcached always sees a callback even if ExpressBrute isn't given one.
v0.4.1
- NEW:
refreshTimeoutOnRequestoption that allows you to prevent the remaininglifetimefor a timer from being reset on each request (useful for implementing limits for set time frames, e.g. requests per day) - BUG: Lifetimes were not previously getting extended properly for instances of
ExpressBrute.MemoryStore
v0.4.0
- NEW:
attachResetToRequestparameter that lets you prevent the request object being decorated - NEW:
failCallbackcan be overriden bygetMiddleware - NEW:
proxyDepthoption onExpressBrutethat specifies how many levels of theX-Forwarded-Forheader to trust (inspired by express-bouncer). - NEW:
getIPFromRequestmethod that essentially allowsresetto used in a similar ways as in v0.2.2. This also respects the newproxyDepthsetting. - CHANGED:
getMiddlewarenow takes an options object instead of the key directly.
v0.3.0
- NEW: Support for using custom keys to group requests further (e.g. grouping login requests by username)
- NEW: Support for middleware from multiple instances of
ExpressBruteon the same route. - NEW: Tracking
lifetimenow has a reasonable default derived from the other settings for that instance ofExpressBrute - NEW: Keys are now hashed before saving to a store, to prevent really long key names and reduce the possibility of collisions.
- NEW: There is now a convience method that gets attached to
reqobject asreq.brute.reset. It takes a single parameter (a callback), and will reset all the counters used byExpressBrutemiddleware that was called for the current route. - CHANGED: Tracking
lifetimeis now specified onExpressBruteinstead ofMemcachedStore. This also means lifetime is now supported by MemoryStore. - CHANGED: The function signature for
ExpressBrute.resethas changed. It now requires an IP and key be passed instead of a request object. - IMPROVED: Efficiency for large values of
freeRetries. - BUG: Removed a small chance of incorrectly triggering brute force protection.