文档教程后端【免费下载链接】nodebestpractices✅ The Node.js best practices list (July 2026)项目地址https://gitcode.com/GitHub_Trending/no/nodebestpractices点击查看免费下载/loginや/adminのような高特権ルートをレートリミットなしで公開し続けると、パスワード辞書によるブルートフォース攻撃の標的になります。本記事では、オープンソースの Node.js ベストプラクティス集 nodebestpractices の「認証に対するブルートフォース攻撃を阻止する」セクションを中心に、rate-limiter-flexibleを用いた「ユーザー名IP ペア」と「IP アドレス単体」の二段構えのリミッター設計を解説します。読者は、認証系ルートに実装すべきレートリミット戦略、具体的な設定パラメータの意味、および Express や nginx を含む補助的な防御策まで、そのまま実戦投入できる知識を獲得できます。なぜ認証ルートにレートリミットが必須なのかレートリミットを行わずに/loginや/adminのような高特権ルートを公開したままにしておくと、アプリケーションはブルートフォースパスワード辞書攻撃のリスクに晒されます。攻撃者は大量のユーザー名パスワードの組み合わせを機械的に送信し続け、正しい組み合わせを見つけ出すまで試行を繰り返します。このような攻撃はログインエンドポイントに限らず、公開された RESTful API の他の部分にも向けられる可能性があります後述の 他ブロガーの見解 も参照。この攻撃の成功を防ぐには、リクエストのプロパティIP アドレスなどや body パラメータユーザー名メールアドレスなどに基づいて、認証試行の許可回数を制限する戦略を採用します。nodebestpractices のセキュリティセクションでは、この方針を「認証に対するブルートフォース攻撃を阻止する」ベストプラクティスとして sections/security/login-rate-limit.md に体系的にまとめています。二重リミッター設計rate-limiter-flexibleによる防御の全体像本プラクティスの核となるのは、npm パッケージrate-limiter-flexibleを使って2 つのリミッターを組み合わせることです。単一の制限だけでは、IP 単位で弾いても分散攻撃に弱く、ユーザー名単位で弾いても別ユーザーへの攻撃を許してしまうため、粒度の異なる 2 つの制限を重ねるのがポイントです。1 つ目連続した認証失敗回数をカウントし、ユーザー名と IP アドレスのペアに対して最大 10 回まで許可する2 つ目1 日に 100 回試行に失敗した IP アドレスを 1 日ブロックするこの「ユーザー名×IP」と「IP 単体」の組み合わせは、同一アカウントへの集中的な辞書攻撃と、多数アカウントへの分散攻撃の両方に対応できる現実的な設計です。コード例2 つの RateLimiterRedis の構築以下は sections/security/login-rate-limit.japanese.md のコード例をそのまま踏襲した、Redis バックエンド版の実装です。const maxWrongAttemptsByIPperDay 100; const maxConsecutiveFailsByUsernameAndIP 10; const limiterSlowBruteByIP new RateLimiterRedis({ storeClient: redisClient, keyPrefix: login_fail_ip_per_day, points: maxWrongAttemptsByIPperDay, duration: 60 * 60 * 24, blockDuration: 60 * 60 * 24, // 1 日に 100 回失敗した場合、1 日間ブロックする }); const limiterConsecutiveFailsByUsernameAndIP new RateLimiterRedis({ storeClient: redisClient, keyPrefix: login_fail_consecutive_username_and_ip, points: maxConsecutiveFailsByUsernameAndIP, duration: 60 * 60 * 24 * 90, // 最初の失敗から 90 日、間数字を保持する blockDuration: 60 * 60, // 1 時間ブロックする });各パラメータの実務的な意味RateLimiterRedisの設定項目は、実際の防御強度を左右するため、一つずつ理解しておく必要があります。パラメータ意味本例での値と意図storeClientカウンタを保持する Redis クライアントredisClient例ではioredisインスタンスを想定keyPrefixRedis キーの接頭辞。リミッターごとに分離するlogin_fail_ip_per_day/login_fail_consecutive_username_and_ippoints許容する最大消費ポイント数 最大試行回数IP 単位で 100、ユーザー名×IP ペアで 10durationポイントが消費されてからリセットされるまでの秒数計測ウィンドウIP 単位は 1 日60 * 60 * 24、ペア単位は 90 日blockDurationポイントを使い切った場合にブロックを継続する秒数IP 単位は 1 日、ペア単位は 1 時間設計上のポイントlimiterSlowBruteByIPは「遅いslowブルートフォース」を防ぐための長期ウィンドウ長期ブロック。1 日に 100 回失敗した IP を丸ごと 1 日締め出します。limiterConsecutiveFailsByUsernameAndIPは短期集中の連続失敗を防ぐためのリミッター。カウンタは最初の失敗から 90 日間保持され、10 回連続失敗で 1 時間ブロックされます。90 日という長期保持により、時間を空けて試行を再開する「スロー攻撃」もカウントに含めて検知できます。ログインエンドポイントへの統合リミッターを実際に機能させるには、認証処理の中でconsumeを呼び出し、ブロック状態であれば HTTP 429 を返す必要があります。nodebestpractices の関連セクション sections/security/limitrequests.md では、純粋な Node.js アプリでrate-limiter-flexibleを使うパターンを示しており、以下のような流れになります。const http require(http); const IoRedis require(ioredis); const { RateLimiterRedis } require(rate-limiter-flexible); const redisClient new IoRedis({ enableOfflineQueue: false }); // Maximum 20 requests per second const rateLimiter new RateLimiterRedis({ storeClient: redisClient, points: 20, duration: 1, blockDuration: 2, // block for 2 seconds if consumed more than 20 points per second }); http.createServer(async (req, res) { try { const rateLimiterRes await rateLimiter.consume(req.socket.remoteAddress); // Some app logic here res.writeHead(200); res.end(); } catch { res.writeHead(429); res.end(Too Many Requests); } }) .listen(3000);このパターンを認証ルートに応用する場合、ペア単位のリミッターはconsume(用户名 _ ip)のようにユーザー名と IP を組み合わせたキーで消費し、失敗時のみポイントを減らす成功時はdeleteでリセットする設計が実務の定番です。consumeが例外を投げた時点でレート超過と判断し、429 Too Many Requestsを返すことで、正当なユーザーへの過剰なブロックを避けつつ攻撃試行を遮断できます。IP 単位だけでは不十分な理由粒度の設計判断IP アドレス単位のみの制限では、以下のような攻撃パターンへの防御が不十分になります。分散攻撃攻撃者が多数の IPボットネットなどから別々のアカウントに対して少量ずつ試行する場合、IP 単位のカウントはそれぞれ 1 〜 数回となり閾値に達しません。NAT やプロキシ配下の誤検知同一 IP を多数の正当ユーザーが共有する環境では、IP 単位の厳しい制限が正規ユーザーのログインを妨げる可能性があります。そのため、本プラクティスは「IP」と「ユーザー名IP ペア」の2 つの異なる粒度を重ねることで、攻撃者の成功率を下げつつ正当ユーザーへの影響を最小化しています。さらに、nodebestpractices の sections/security/commonsecuritybestpractices.md にある OWASP A2Broken Authentication対策とも整合しており、同ドキュメントは「一定期間Y内にX回以上のログイン試行パスワードリカバリ等を含むを許可しない」という認証レートリミットの原則を明記しています。Express アプリでの代替実装express-rate-limit と nginx の併用rate-limiter-flexibleは汎用性が高く Redis ベースでスケールしますが、Express アプリではミドルウェア型のexpress-rate-limitも有力な選択肢です。sections/security/limitrequests.md では、特定ルートにのみ適用するミドルウェア例が示されています。const RateLimit require(express-rate-limit); // important if behind a proxy to ensure client IP is passed to req.ip app.enable(trust proxy); const apiLimiter new RateLimit({ windowMs: 15 * 60 * 1000, // 15 minutes max: 100, }); // only apply to requests that begin with /user/ app.use(/user/, apiLimiter);ここで注意すべきはapp.enable(trust proxy)です。リバースプロキシの背後ではクライアント IP がX-Forwarded-For経由で渡されるため、これを有効にしないと正しいクライアント IP をreq.ipで取得できず、全リクエストが同一 IPプロキシとしてカウントされる問題が発生します。本番構成ではプロキシ設定とセットで検討すべき設定です。さらに、レートリミットはアプリケーション層よりむしろnginx のような専用サービスで行うのが最善とされており、同セクションの nginx の見解後述の「補足の知見」参照は、DDoS 防御やブルートフォース緩和にもレートリミットが有効であることを支持しています。アプリ内リミッターは、nginx 層で制御しきれないビジネスロジック単位の制限ユーザー名×IP などを補完する位置づけとして併用するのが実践的です。他のブロガーの見解[Liran Tal] による書籍Essential Node.js Securityより、本トピックの背景となる攻撃の性質についてブルートフォース攻撃は、攻撃者が一連のユーザー名とパスワードのペアを REST エンドポイントに対して POST したり、開放しているその他の RESTful API に対してリクエストを送信する場合に採用されることがあります。このような辞書攻撃はとても簡単で実行しやすく、ログインとは関係なく、API やページルーティングの他の部分に対しても実行される可能性があります。この指摘は、レートリミットをログインエンドポイントだけに限定せず、認証に関わるすべての高特権ルートパスワードリセット、管理者 API などへ広げるべき理由を示しています。nodebestpractices の sections/security/commonsecuritybestpractices.md も、「パスワードリカバリ等を含む」試行をレートリミット対象に含めるよう明示しており、防御範囲の設計指針として一致しています。防御を完成させるための関連プラクティス認証系のセキュリティを全体として高めるには、レートリミット単体ではなく、以下の関連プラクティスと組み合わせるのが効果的です。いずれも nodebestpractices のセキュリティセクションに収録されています。パスワードの安全な保存sections/security/userpasswords.md では、bcryptコスト 12 以上、scrypt、PBKDF2によるハッシュ化とソルト付与を推奨。ハッシュ化自体もブルートフォース攻撃の「コスト」を引き上げる防御です。認証エラーの情報隠蔽sections/security/commonsecuritybestpractices.md は、ログイン失敗時に「ユーザー名とパスワードのどちらが間違っているか」をユーザーに知らせず、共通の認証エラーのみ返すことを推奨しています。レートリミット全般sections/security/limitrequests.md は、認証以外も含む同時リクエスト数への制限nginx、rate-limiter-flexible、express-rate-limitを扱っており、本記事の二重リミッター設計の兄弟プラクティスです。ブルートフォースの観測認証失敗数の異常をアラートする運用は、sections/security/commonsecuritybestpractices.md の OWASP A10Insufficient Logging Monitoringでも「ログイン失敗の異常量へのアラート」として推奨されています。まとめ実装チェックリスト本プラクティスを本番環境へ適用する際の要点を整理します。高特権ルート/login、/admin、パスワードリセット等には必ずレートリミットを導入する。rate-limiter-flexibleで「ユーザー名IP ペアの連続失敗10 回 → 1 時間ブロック」「IP の日次失敗100 回 → 1 日ブロック」の 2 つのリミッターを定義する。認証失敗時のみポイントを消費し、成功時にカウンタをリセットする。レート超過時は HTTP 429 を返し、クライアントに明確なシグナルを出す。プロキシ配下ではtrust proxy設定を適切に行い、正しいクライアント IP を取得する。レートリミットはアプリ内だけでなく、nginx などのインフラ層とも併用する。パスワードのハッシュ化、認証エラーの情報隠蔽、失敗量の監視アラートと合わせて多層防御を構成する。レートリミットは「正規ユーザーの利便性を守りながら、攻撃者の試行コストを劇的に引き上げる」ための設計です。閾値points、ウィンドウduration、ブロック時間blockDurationは、アプリケーションの利用実態に合わせて調整し、過剰ブロックによる正規ユーザーへの影響をモニタリングしながらチューニングしてください。赞分享文档教程后端【免费下载链接】nodebestpractices✅ The Node.js best practices list (July 2026)项目地址https://gitcode.com/GitHub_Trending/no/nodebestpractices点击查看免费下载相关推荐es-toolkit medianByBigInt完全ガイドオブジェクト配列から中央値を安全・正確に計算するes toolkit medianBy BigInt完全ガイドオブジェクト配列から中央値を安全・正確に計算する medianBy は、es toolkit前端后端GetQzonehistory3 条命令把 QQ 空间全部历史说说导出到本地GetQzonehistory3 条命令把 QQ 空间全部历史说说导出到本地 GetQzonehistory 是一个开源的 QQ 空间历史说说导出工具它模拟网页爬虫数据分析Skyvern 如何用 max_steps 与引擎选择控制 Cloud 任务成本Skyvern 如何用 max_steps 与引擎选择控制 Cloud 任务成本 Skyvern Cloud 采用按 credit 计费AI 每次执行一个浏文档教程后端上一篇TypeDoc 外部文档指南用 document 标签与 projectDocuments 选项将独立 Markdown 文件纳入文档站下一篇红队持久化攻击全攻略基于gh_mirrors/re/redteam的后门脚本实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考