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類似パッケージ:

Express.js アプリケーションにおけるレート制限パッケージの比較

express-brute、express-limiter、express-rate-limit、express-slow-down、rate-limiter-flexible は、すべて Express.js アプリケーションでレート制限（アクセス制限）を実装するためのミドルウェアパッケージです。これらは API エンドポイントへの過剰なリクエストを防ぎ、DDoS 攻撃やブルートフォース攻撃からアプリケーションを保護します。express-rate-limit が最も広く採用されており、rate-limiter-flexible は柔軟なストア対応が特徴です。express-slow-down はリクエストをブロックせず速度を落とすアプローチを取ります。

npmのダウンロードトレンド

3 年

GitHub Starsランキング

統計詳細

パッケージ
ダウンロード数
Stars
サイズ
Issues
公開日時
ライセンス
express-brute23,061568-219年前BSD
express-limiter0423-219年前MIT
express-rate-limit03,241142 kB98日前MIT
express-slow-down029937.6 kB11ヶ月前MIT
rate-limiter-flexible03,512220 kB134日前ISC

Express.js レート制限パッケージ：技術比較と実装ガイド

Express.js アプリケーションで API 保護を実装する際、適切なレート制限パッケージの選択はセキュリティとパフォーマンスに直結します。express-brute、express-limiter、express-rate-limit、express-slow-down、rate-limiter-flexible の 5 つのパッケージは、それぞれ異なるアプローチと特徴を持っています。実務での選択基準を明確にするために、技術的な違いを深掘りします。

📦 パッケージの現状とメンテナンス状態

express-brute は 2015 年頃から存在する古いパッケージで、現在はアクティブなメンテナンスが行われていません。

// express-brute: 古い API スタイル
const ExpressBrute = require('express-brute');
const store = new ExpressBrute.MemoryStore();
const bruteforce = new ExpressBrute(store);

app.post('/login', bruteforce.prevent, loginHandler);

express-limiter も同様に更新が停滞しており、Redis 特化型の制限ミドルウェアです。

// express-limiter: Redis 必須
const expressLimiter = require('express-limiter');
const redis = require('redis');
const client = redis.createClient();

expressLimiter(app, client, {
  lookup: 'connection.remoteAddress',
  total: 100,
  expire: 1000 * 60 * 60
});

express-rate-limit は現在もアクティブにメンテナンスされており、npm で最もダウンロードされています。

// express-rate-limit: 現代的な API
const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
  message: 'リクエストが多すぎます'
});

app.use('/api/', limiter);

express-slow-down は express-rate-limit の作者によって作成され、同じエコシステムで動作します。

// express-slow-down: 遅延による制限
const slowDown = require('express-slow-down');

const speedLimiter = slowDown({
  windowMs: 15 * 60 * 1000,
  delayAfter: 50,
  delayMs: 500
});

app.use('/api/', speedLimiter);

rate-limiter-flexible は最新の設計で、複数のストレージバックエンドを公式にサポートしています。

// rate-limiter-flexible: 柔軟なストア対応
const { RateLimiterRedis } = require('rate-limiter-flexible');

const rateLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  points: 10,
  duration: 1
});

app.use('/api/', (req, res, next) => {
  rateLimiter.consume(req.ip)
    .then(() => next())
    .catch(() => res.status(429).send('制限超過');
});

🔧 ストレージバックエンドの対応状況

ストレージ選択は、アプリケーションのスケールに直接影響します。

パッケージメモリRedisMongoDBMemcachedその他
express-brute✅✅❌❌カスタムストア可能
express-limiter❌✅❌❌Redis のみ
express-rate-limit✅✅✅✅公式ストア多数
express-slow-down✅✅✅✅express-rate-limit と共通
rate-limiter-flexible✅✅✅✅15+ ストア対応

express-rate-limit のストア設定例：

const RedisStore = require('rate-limit-redis');
const { createClient } = require('redis');

const limiter = rateLimit({
  store: new RedisStore({
    sendCommand: (...args) => redisClient.sendCommand(args)
  }),
  windowMs: 15 * 60 * 1000,
  max: 100
});

rate-limiter-flexible のストア設定例：

const { RateLimiterMongo } = require('rate-limiter-flexible');
const { MongoClient } = require('mongodb');

const rateLimiter = new RateLimiterMongo({
  storeClient: mongoClient,
  tableName: 'rateLimits',
  points: 10,
  duration: 1
});

🎯 制限ロジックの実装アプローチ

各パッケージは異なる方法でリクエストをカウントし、制限を適用します。

express-brute は失敗カウントに特化しており、ログイン試行などのブルートフォース対策に適しています。

// express-brute: 失敗時のみカウント
bruteforce.handleFailures((req, res, next, nextValidRequestDate) => {
  if (req.body.username === 'admin') {
    return res.status(403).send('アカウントロック中');
  }
  next();
});

express-limiter は単純なカウントベースで、Redis の TTL 機能を利用します。

// express-limiter: シンプルカウント
expressLimiter(app, client, {
  lookup: 'headers.api-key',
  total: 1000,
  expire: 1000 * 60 * 60,
  onRateLimited: (req, res) => {
    res.status(429).send('レート制限超過');
  }
});

express-rate-limit は柔軟なキー生成とカスタムメッセージをサポートします。

// express-rate-limit: カスタムキー生成
const limiter = rateLimit({
  keyGenerator: (req) => {
    return req.user?.id || req.ip;
  },
  handler: (req, res) => {
    res.status(429).json({
      error: '制限超過',
      retryAfter: Math.ceil(res.get('Retry-After'))
    });
  }
});

express-slow-down はブロックではなく遅延を適用します。

// express-slow-down: 段階的遅延
const speedLimiter = slowDown({
  delayAfter: 50,
  delayMs: (hits) => Math.min(hits * 100, 60000),
  skipFailedRequests: true
});

rate-limiter-flexible はポイントベースのシステムで、異なるアクションに異なるコストを設定できます。

// rate-limiter-flexible: ポイントベース
const rateLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  points: 100,
  duration: 60
});

// 重い操作は更多ポイント消費
await rateLimiter.consume(userId, 5); // 5 ポイント消費

⚠️ エラーハンドリングとレスポンス

制限超過時のレスポンス制御は、ユーザー体験に影響します。

express-brute はカスタムエラーハンドラを登録します：

bruteforce.getMiddleware({
  onBlocked: (req, res, next, nextValidRequestDate) => {
    res.status(429).json({
      error: '一時的にブロックされています',
      retryAfter: nextValidRequestDate
    });
  }
});

express-rate-limit は標準 HTTP ヘッダーを自動設定します：

// 自動設定されるヘッダー
// X-RateLimit-Limit: 100
// X-RateLimit-Remaining: 95
// X-RateLimit-Reset: 1640000000
// Retry-After: 60

rate-limiter-flexible は詳細な制限情報を返します：

try {
  const response = await rateLimiter.consume(key);
  res.set('Retry-After', Math.ceil(response.msBeforeNext / 1000));
  next();
} catch (rej) {
  res.set('Retry-After', Math.ceil(rej.msBeforeNext / 1000));
  res.status(429).json({
    pointsRemaining: rej.remainingPoints,
    msBeforeNext: rej.msBeforeNext
  });
}

🏗️ 実運用での選択基準

小規模プロジェクト（メモリストアで十分）

推奨：express-rate-limit

設定がシンプルで、デフォルトのメモリストアでも十分な場合：

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
  standardHeaders: true,
  legacyHeaders: false
});

app.use('/api/', limiter);

中規模プロジェクト（Redis 必要）

推奨：express-rate-limit または rate-limiter-flexible

複数サーバー環境で Redis を使用する場合：

// express-rate-limit + Redis
const limiter = rateLimit({
  store: new RedisStore({ sendCommand: redisClient.sendCommand }),
  windowMs: 15 * 60 * 1000,
  max: 100
});

// rate-limiter-flexible + Redis
const rateLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  points: 100,
  duration: 900
});

大規模プロジェクト（複雑な制限ロジック）

推奨：rate-limiter-flexible

異なるエンドポイントで異なる制限を適用する場合：

const loginLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  points: 5,
  duration: 300
});

const apiLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  points: 1000,
  duration: 3600
});

app.post('/login', async (req, res, next) => {
  try {
    await loginLimiter.consume(req.ip);
    next();
  } catch {
    res.status(429).send('ログイン試行が多すぎます');
  }
});

ユーザー体験を重視する場合

推奨：express-slow-down + express-rate-limit 併用

いきなりブロックせず、段階的に制限：

const limiter = rateLimit({ windowMs: 900000, max: 100 });
const speedLimiter = slowDown({ windowMs: 900000, delayAfter: 50, delayMs: 200 });

app.use('/api/', speedLimiter);
app.use('/api/', limiter);

🚫 非推奨パッケージの扱い

express-brute と express-limiter は、新しいプロジェクトでの使用を避けるべきです：

  • 最終更新から長期間経過
  • セキュリティ修正がされていない可能性
  • 現代的な Node.js バージョンとの互換性問題
  • コミュニティサポートが限定的

既存システムで使用している場合は、移行計画を立てることを推奨します：

// 移行例：express-brute → express-rate-limit
// 旧コード
app.post('/login', bruteforce.prevent, loginHandler);

// 新コード
const loginLimiter = rateLimit({
  windowMs: 5 * 60 * 1000,
  max: 5,
  message: 'ログイン試行が多すぎます'
});

app.post('/login', loginLimiter, loginHandler);

📊 機能比較サマリー

機能express-bruteexpress-limiterexpress-rate-limitexpress-slow-downrate-limiter-flexible
メンテナンス❌ 停滞❌ 停滞✅ アクティブ✅ アクティブ✅ アクティブ
Redis 対応✅✅✅✅✅
メモリストア✅❌✅✅✅
カスタムキー⚠️ 限定的⚠️ 限定的✅✅✅
ポイントシステム❌❌❌❌✅
遅延機能❌❌❌✅⚠️ 要実装
TypeScript❌❌✅✅✅
新規推奨❌❌✅✅✅

💡 最終的な推奨事項

新規プロジェクトでの選択フロー：

  1. シンプルな API 保護が必要 → express-rate-limit
  2. Redis 環境が既に整っている → express-rate-limit または rate-limiter-flexible
  3. 複雑な制限ロジックが必要 → rate-limiter-flexible
  4. ユーザー体験を重視 → express-slow-down + express-rate-limit
  5. レガシーシステム維持 → 移行計画を立てて express-rate-limit へ

重要な注意点：

  • express-brute と express-limiter は新規プロジェクトで使用しないでください
  • 本番環境では必ず Redis などの永続ストアを使用してください
  • メモリストアは単一サーバー環境でのみ使用可能です
  • レート制限はセキュリティ層の一つであり、他の対策と併用してください

レート制限パッケージの選択は、アプリケーションの規模、インフラ構成、セキュリティ要件によって異なります。express-rate-limit が最もバランスの取れた選択肢ですが、大規模システムでは rate-limiter-flexible の柔軟性が活きます。ユーザー体験を重視する場合は express-slow-down の併用を検討してください。

選び方: express-brute vs express-limiter vs express-rate-limit vs express-slow-down vs rate-limiter-flexible

  • express-brute:

    express-brute は古いパッケージで、現在はメンテナンスが停滞しています。ブルートフォース攻撃対策に特化していますが、新しいプロジェクトでの使用は推奨されません。既存のレガシーシステムで既に導入されている場合のみ検討し、新規プロジェクトでは express-rate-limit や rate-limiter-flexible の評価を推奨します。

  • express-limiter:

    express-limiter は Redis をストレージバックエンドとして使用する場合に適しています。Redis 環境が既に整っており、シンプルな設定で済ませたいプロジェクトに向いています。ただし、複数のストレージオプションを必要とする場合は rate-limiter-flexible の方が柔軟です。

  • express-rate-limit:

    express-rate-limit は最も成熟しており、コミュニティサポートが厚いパッケージです。シンプルな設定で始められ、メモリストアから Redis まで対応しています。新規プロジェクトで迷った場合の第一選択肢として推奨され、ドキュメントも充実しています。

  • express-slow-down:

    express-slow-down はリクエストを完全にブロックせず、応答を遅延させるアプローチを取ります。ユーザー体験を損なわずに悪意のあるトラフィックを抑制したい場合に適しています。express-rate-limit と併用して、段階的な制限を実現できます。

  • rate-limiter-flexible:

    rate-limiter-flexible は最も柔軟で、Redis、Memcached、MongoDB など複数のストアをサポートします。マイクロサービス環境や複雑な制限ロジックが必要な場合に適しています。学習コストはやや高いですが、大規模システムでの拡張性が高いです。

express-bruteと類似したnpmパッケージ

express-brute は、Node.js の Express アプリケーション向けの強力なレート制限ミドルウェアです。このパッケージは、特定のルートやリクエストに対して攻撃を防ぐために、リクエストの数を制限するのに役立ちます。express-brute は、簡単に設定できる柔軟なオプションを提供し、さまざまなストレージバックエンド（メモリ、Redis、MongoDB など）をサポートしています。これにより、開発者はアプリケーションのニーズに合わせてレート制限をカスタマイズできます。

express-brute の代替として、以下のようなパッケージがあります：

  • express-limiter は、Express アプリケーション向けのシンプルなレート制限ミドルウェアです。このパッケージは、リクエストの制限を簡単に設定でき、特定の時間枠内でのリクエスト数を制御します。express-limiter は、シンプルな API を提供し、迅速に導入できるため、小規模なプロジェクトやシンプルなレート制限が必要な場合に適しています。
  • express-rate-limit は、Express アプリケーション向けの人気のあるレート制限ミドルウェアです。これは、特定の時間枠内でのリクエスト数を制限するための簡単な方法を提供し、リクエストの制限を設定するための柔軟なオプションを持っています。express-rate-limit は、特にセキュリティを強化したいアプリケーションにおいて、一般的に使用される選択肢です。
  • express-slow-down は、リクエストのレート制限を行うだけでなく、特定の条件に基づいてリクエストの応答を遅延させることができるミドルウェアです。これにより、攻撃者がアプリケーションに対して過剰なリクエストを送信するのを防ぎつつ、正当なユーザーに対してはスムーズな体験を提供します。
  • rate-limiter-flexible は、Node.js アプリケーション向けの柔軟なレート制限ライブラリです。このライブラリは、さまざまなストレージバックエンドをサポートし、複雑なレート制限のシナリオに対応できます。rate-limiter-flexible は、特に高トラフィックのアプリケーションや、より高度なレート制限が必要な場合に適しています。

これらのパッケージの比較については、こちらをご覧ください：express-brute vs express-limiter vs express-rate-limit vs express-slow-down vs rate-limiter-flexible の比較。

express-limiterと類似したnpmパッケージ

express-limiterは、Node.jsのExpressアプリケーションにおけるリクエストの制限を行うためのミドルウェアです。このパッケージは、特定の条件に基づいてリクエストの数を制限することで、サーバーの過負荷を防ぎ、サービスの安定性を向上させます。express-limiterは、シンプルで使いやすいAPIを提供し、開発者が迅速にリクエスト制限を実装できるように設計されています。しかし、他にも同様の機能を持つライブラリがいくつか存在します。以下にいくつかの代替ライブラリを紹介します。

  • express-bruteは、リクエストの制限を行うための強力なミドルウェアです。express-bruteは、リクエストの制限を行うための柔軟な設定を提供し、ストレージバックエンド（メモリ、Redis、MongoDBなど）を選択することができます。これにより、開発者はアプリケーションのニーズに応じてリクエスト制限のロジックをカスタマイズできます。

  • express-rate-limitは、Expressアプリケーションのためのシンプルで効果的なリクエスト制限ミドルウェアです。このライブラリは、IPアドレスや特定のルートに基づいてリクエストの数を制限する機能を提供します。express-rate-limitは、設定が簡単で、すぐに使用できるため、リクエスト制限を迅速に実装したい場合に適しています。

  • express-slow-downは、リクエストの制限を行うだけでなく、特定の条件に基づいてリクエストの応答時間を遅延させることができるミドルウェアです。このアプローチは、悪意のあるリクエストを抑制し、サーバーへの負荷を軽減するのに役立ちます。リクエストを単にブロックするのではなく、遅延させることで、ユーザーに対してより良い体験を提供します。

  • rate-limiter-flexibleは、柔軟で高性能なリクエスト制限ライブラリで、Expressアプリケーションだけでなく、さまざまなNode.jsアプリケーションで使用できます。このライブラリは、メモリやRedisなどのストレージを使用して、リクエスト制限を行うための高度な機能を提供します。特に、分散システムやスケーラブルなアプリケーションにおいて、リクエスト制限を効果的に管理するために適しています。

これらのライブラリの比較については、以下のリンクをご覧ください: Comparing express-brute vs express-limiter vs express-rate-limit vs express-slow-down vs rate-limiter-flexible。

express-rate-limitと類似したnpmパッケージ

express-rate-limit は、Node.js の Express アプリケーション向けに設計されたミドルウェアで、リクエストのレート制限を簡単に実装できます。このパッケージを使用することで、特定の IP アドレスからのリクエスト数を制限し、DoS 攻撃や不正利用からアプリケーションを保護することができます。express-rate-limit は、シンプルで使いやすく、設定も容易なため、多くの開発者に利用されています。

以下は、express-rate-limit の代替となるいくつかのパッケージです：

  • express-brute は、リクエストのレート制限を行うためのミドルウェアで、さまざまなストレージバックエンドをサポートしています。express-brute は、リクエストの制限を柔軟に設定できるため、特定の条件に基づいて制限を変更したい場合に適しています。例えば、特定のエンドポイントやメソッドに対して異なる制限を設けることが可能です。

  • express-slow-down は、リクエストのレート制限を行う代わりに、リクエストの応答を遅延させるミドルウェアです。これにより、攻撃者が大量のリクエストを送信しても、サーバーの応答速度を低下させることで、リソースの消費を抑えることができます。express-slow-down は、特にリクエストの数が多い場合に効果的です。

  • rate-limiter-flexible は、より柔軟なレート制限を提供するパッケージで、Redis や MongoDB などのデータストアを使用して、分散環境でも効果的に機能します。このパッケージは、リクエストの制限を動的に変更したり、異なる条件に基づいて制限を設定したりすることができるため、大規模なアプリケーションに適しています。

これらのパッケージの比較については、以下のリンクをご覧ください：Comparing express-brute vs express-rate-limit vs express-slow-down vs rate-limiter-flexible.

express-slow-downと類似したnpmパッケージ

express-slow-down は、Express アプリケーションにおいてリクエストの速度を制限するためのミドルウェアです。このパッケージは、特定の時間内にリクエストを送信するクライアントを遅延させることで、サーバーへの過負荷を防ぎ、悪意のある攻撃から保護します。express-slow-down は、特に DoS 攻撃やブルートフォース攻撃からの防御に役立ちますが、他にもいくつかの代替パッケージがあります。

  • express-brute は、Express アプリケーションのための強力なブルートフォース攻撃防止ミドルウェアです。リクエストの数を制限し、特定の条件を満たさない場合にリクエストを拒否することができます。express-brute は、ストレージオプションを提供しており、Redis や MongoDB などの外部ストレージを使用してリクエストの状態を管理することができます。これにより、分散システムにおいても効果的に機能します。

  • express-rate-limit は、リクエストのレート制限を行うためのシンプルで使いやすいミドルウェアです。このパッケージは、特定の時間内に許可されるリクエストの数を制限し、過剰なリクエストを行うクライアントをブロックします。express-rate-limit は、簡単に設定でき、さまざまなストレージオプションをサポートしているため、一般的なレート制限のニーズに適しています。

  • rate-limiter-flexible は、柔軟なレート制限を提供するためのパッケージで、Express アプリケーションだけでなく、他の Node.js アプリケーションでも使用できます。このライブラリは、複雑なレート制限の要件に対応できるように設計されており、Redis や MongoDB などのストレージを利用して、リクエストの状態を管理することができます。rate-limiter-flexible は、特に高トラフィックのアプリケーションにおいて、効率的なレート制限を実現します。

これらのパッケージの比較については、こちらをご覧ください: Comparing express-brute vs express-rate-limit vs express-slow-down vs rate-limiter-flexible。

rate-limiter-flexibleと類似したnpmパッケージ

rate-limiter-flexible は、Node.js アプリケーション向けの柔軟なレート制限ライブラリです。このライブラリは、API やサービスへのリクエストを制限するために使用され、過剰なリクエストからシステムを保護します。rate-limiter-flexible は、さまざまなストレージバックエンド（メモリ、Redis、MongoDB など）をサポートし、シンプルで使いやすい API を提供します。以下は、このライブラリの代替品です。

  • bottleneck は、Node.js およびブラウザ向けのレート制限ライブラリです。bottleneck は、非同期タスクの実行を制御するための強力なツールであり、タスクのスロットリングやバッチ処理を簡単に行うことができます。特に、API リクエストの制限や、特定の時間内に実行するタスクの数を制御したい場合に便利です。シンプルな構文で、柔軟性が高いのが特徴です。
  • express-rate-limit は、Express.js アプリケーション向けのミドルウェアで、HTTP リクエストのレート制限を簡単に実装できます。このライブラリは、特定の IP アドレスからのリクエスト数を制限するために使用され、悪意のある攻撃やスパムからアプリケーションを保護します。express-rate-limit は、設定が簡単で、Express.js とシームレスに統合できるため、Express アプリケーションでの使用に最適です。
  • limiter は、シンプルで軽量なレート制限ライブラリで、Node.js アプリケーションでの使用を目的としています。limiter は、リクエストの数を制御し、過剰なリクエストからシステムを保護するための基本的な機能を提供します。シンプルな API を持ち、すぐに使い始めることができるため、小規模なプロジェクトやシンプルなレート制限が必要な場合に適しています。

これらのライブラリの比較を確認するには、こちらをご覧ください: bottleneck vs express-rate-limit vs limiter vs rate-limiter-flexible。

express-brute のREADME

express-brute

NPM Version NPM Downloads Build Status Coverage Status Dependency Status

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)

  • store An instance of ExpressBrute.MemoryStore or some other ExpressBrute store (see a list of known stores below).
  • options
    • freeRetries The number of retires the user has before they need to start waiting (default: 2)
    • minWait The initial wait time (in milliseconds) after the user runs out of retries (default: 500 milliseconds)
    • maxWait The 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.
    • lifetime The 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 to maxWait * the number of attempts before you hit maxWait to discourage simply waiting for the lifetime to expire before resuming an attack. With default values this is about 6 hours.
    • failCallback Gets called with (req, resp, next, nextValidRequestDate) when a request is rejected (default: ExpressBrute.FailForbidden)
    • attachResetToRequest Specify whether or not a simplified reset method should be attached at req.brute.reset. The simplified method takes only a callback, and resets all ExpressBrute middleware that was called on the current request. If multiple instances of ExpressBrute have middleware on the same request, only those with attachResetToRequest set to true will be reset (default: true)
    • refreshTimeoutOnRequest Defines whether the lifetime counts 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 info
    • handleStoreError Gets called whenever an error occurs with the persistent store from which ExpressBrute cannot recover. It is passed an object containing the properties message (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 during reset or 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 calling failCallback. Equivilent to getMiddleware(null)
  • getMiddleware(options) Generates middleware that will bounce requests with the same key and IP address that happen faster than the current wait time by calling failCallback. Also attaches a function at req.brute.reset that can be called to reset the counter for the current ip and key. This functions as the reset instance method, but without the need to explicitly pass the ip and key paramters
    • key can be a string or alternatively it can be a function(req, res, next) that or calls next, passing a string as the first parameter.
    • failCallback Allows you to override the value of failCallback for this middleware
    • ignoreIP Disregard IP address when matching requests if set to true. Defaults to false.
  • reset(ip, key, next) Resets the wait time between requests back to its initial value. You can pass null for key if you want to reset a request protected by protect.

Built-in Failure Callbacks

There are some built-in callbacks that come with BruteExpress that handle some common use cases.

  • ExpressBrute.FailTooManyRquests Terminates the request and responses with a 429 (Too Many Requests) error that has a Retry-After header and a JSON error message.
  • ExpressBrute.FailForbidden Terminates the request and responds with a 403 (Forbidden) error that has a Retry-After header and a JSON error message. This is provided for compatibility with ExpressBrute versions prior to v0.5.0, for new users FailTooManyRequests is the preferred behavior.
  • ExpressBrute.FailMark Sets 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 Express 4.x as a peer dependency.
  • REMOVED: proxyDepth option on ExpressBrute has been removed. Use app.set('trust proxy', x) from Express 4 instead. More Info
  • REMOVED: getIPFromRequest(req) has been removed from instances, use req.ip instead.

v0.6.0

  • NEW: Added new ignoreIP option. (Thanks Magnitus-!)
  • CHANGED: .reset callbacks are now always called asyncronously, regardless of the implementation of the store (particularly effects MemoryStore).
  • 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 handleStoreError option 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 FailTooManyRequests failure 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. FailForbidden remains 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: FailMark no 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: refreshTimeoutOnRequest option that allows you to prevent the remaining lifetime for 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: attachResetToRequest parameter that lets you prevent the request object being decorated
  • NEW: failCallback can be overriden by getMiddleware
  • NEW: proxyDepth option on ExpressBrute that specifies how many levels of the X-Forwarded-For header to trust (inspired by express-bouncer).
  • NEW: getIPFromRequest method that essentially allows reset to used in a similar ways as in v0.2.2. This also respects the new proxyDepth setting.
  • CHANGED: getMiddleware now 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 ExpressBrute on the same route.
  • NEW: Tracking lifetime now has a reasonable default derived from the other settings for that instance of ExpressBrute
  • 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 req object as req.brute.reset. It takes a single parameter (a callback), and will reset all the counters used by ExpressBrute middleware that was called for the current route.
  • CHANGED: Tracking lifetime is now specified on ExpressBrute instead of MemcachedStore. This also means lifetime is now supported by MemoryStore.
  • CHANGED: The function signature for ExpressBrute.reset has 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.
npm-compare.com is an independent website designed to help developers choose the most suitable npm packages. We are not affiliated with npm, Inc, the official website for the npm registry. Note that npm is a registered trademark of npm, Inc. Please share your feedback via our GitHub repository. For more details, please refer to our Terms & Privacy.