Sucuri WAF の誤検知が Stripe Webhook をブロックし続ける理由と、それを阻止した正確な IP ホワイトリスト修正

公開: 2025-11-13

オンライン取引に Stripe を利用している企業は、シームレスな Webhook 通信の重要性を認識しています。しかし、人気のある Web アプリケーションファイアウォール (WAF) である Sucuri が、正規の Stripe Webhook を誤って脅威として識別し始めると、その結果、支払いの中断、トランザクションの失敗、不必要な顧客サポートのオーバーヘッドが発生する可能性があります。このイライラするシナリオに悩んでいるのはあなただけではありません。ありがたいことに、正確な解決策があります。

TL;DR

Stripe Webhook が誤検知により Sucuri WAF によってブロックされている場合、問題は多くの場合、不適切な IP ホワイトリストまたは過剰な WAF ルールによって発生します。 Stripe のサーバーは、WAF 設定で明示的に許可する必要があるさまざまな IP をローテーションします。 Sucuri ファイアウォールを Stripe の公式 IP アドレスで更新し、特定のヒューリスティックルールを無効にすることで、問題を即座に解決し、スムーズな Webhook 機能を復元できます。

問題の理解: Sucuri WAF と誤検知

Sucuri は、DDoS 攻撃、Web サイトのハッキング、その他の悪意のあるアクティビティに対して堅牢な防御を提供します。これは、受信した HTTP リクエストをスクリーニングし、リモートで疑わしいと思われるものをブロックすることによって機能します。これは悪意のある行為者をブロックするのには優れていますが、Stripe のような正規のサービスが Webhook 呼び出しを送信する場合には逆効果になる可能性があります。

Stripe は Webhook を使用して、支払いの成功、トランザクションの失敗、払い戻し、サブスクリプションの変更などの重要なイベントをサーバーに通知します。これらは、顧客記録の更新、在庫管理、収益追跡などのプロセスを自動化するために不可欠です。

この問題は、Sucuri のルール、特に SQL インジェクションまたはコードインジェクションを検出しようとするヒューリスティックフィルターが、Stripe の Webhook ペイロードを誤って悪意のあるものとして分類したときに発生します。

この問題の一般的な症状は次のとおりです。

Stripe ダッシュボードには、Webhook 配信の失敗が繰り返し発生していることが表示されます。
Stripe からの受信 POST リクエストはサーバーログに表示されません。
Stripe は、403 Forbidden エラーまたはタイムアウトエラーが原因でリクエストを複数回再試行します。
Web フックの失敗について警告する Stripe からの電子メール通知。

Sucuri はサイトを保護していますが、最終的には少し攻撃的になりすぎて、ブロックすべきでないものをブロックしてしまう可能性があります。

根本原因の特定: Stripe によって引き起こされる誤検知

サーバーのログと Sucuri のダッシュボードを詳しく調査すると、問題がより明確になりました。各 Stripe Webhook は403 Forbidden応答を受信していたか、サーバーへの到達が完全にブロックされていました。 Sucuri でインシデントログを表示すると、次のフラグが繰り返しトリガーされていました。

SQLi ヒューリスティックパターン
リクエスト本文のサイズがしきい値を超えました
不正な JSON により POST リクエストがブロックされました(JSON が有効な場合でも)

Sucuri は進化する検出アルゴリズムを使用しており、Stripe の JSON ペイロードには、これらのヒューリスティックエンジンがアルゴリズム的に不審なアクティビティとして誤って解釈する文字やパターン (引用符、括弧、特定のキーワードなど) が含まれる場合があります。これにより、Sucuri はリクエストにフラグを立ててドロップし、アプリケーションに到達することを許可しません。

これは、大量のトランザクションによって大量の Webhook が生成され、その多くがどこにも行かなかったプロモーションキャンペーン中に特に問題でした。

適切な修正: 正確な IP ホワイトリスト登録

ファイアウォールを一時的に無効にしたり、Webhook URL に対して全世界をホワイトリストに登録したりすることは誘惑に駆られますが、それはセキュリティ上の悪夢です。正しく安全な修正には、いくつかの戦略的な手順が含まれます。

1. Stripe の公式 IP アドレスを取得する

Stripe は、Webhook の発信元の IP 範囲のリストを公開しています。このリストは公式ドキュメントから入手でき、定期的に更新されます。

執筆時点での IP の例は次のとおりです (注: これらは変更されているため、必ず公式ソースを確認してください)。

3.18.12.63
3.130.192.231
13.235.14.237
13.235.122.149
18.211.135.69
35.154.171.200
52.15.183.38

2. Sucuriのダッシュボードにログインします

Sucuri ファイアウォール設定に移動し、 「アクセス制御」の下にある「ホワイトリスト」セクションを見つけます。ここでは、すべての WAF チェックをバイパスして、通過を許可する正確な IP を手動で入力できます。

3. Stripe のすべての IP をホワイトリストに追加します

Stripe によって提供されるすべての IP ブロックがホワイトリストに追加されていることを確認してください。 Sucuri は厳密な一致を行うため、IP が 1 つでも欠けていると、ランダムな Webhook イベントが断続的に失敗する可能性があります。

4. Webhook エンドポイントのブロックされたアクションを無効にする

Sucuri のURL パス設定では、Webhook リスナーエンドポイント (例: /ストライプ/webhook) を追加し、そのパスに対してのみ特定の WAF ルールを無効にすることができます。これにより、Stripe のリクエストが不必要にブロックされないようにすると同時に、ファイアウォールをグローバルにオフにすることを回避します。ここで最も役立つ設定は次のとおりです。

その特定のパスに対するヒューリスティックフィルタリングを無効にします。
Stripe イベントにメタデータの多いペイロードが含まれる場合は、より大きな POST 本文サイズを許可します。

これにより、エンドポイントは複雑な JSON ペイロードを干渉なく受け入れることができます。

おまけのヒント: Stripe の署名シークレットを使用する

Stripe の IP をホワイトリストに登録した後でも、受信したすべての Webhook リクエストの信頼性を検証することが賢明です。 Stripe は、サーバーが Webhook ペイロードを暗号的に検証できるようにする署名シークレットを提供します。

これにより、他のソースが Stripe の IP を偽装し、Webhook URL にアクセスした場合でも (可能性は低いですが、可能性はあります)、そのリクエストが署名検証に失敗することが保証されます。これを実装するには、ここにある Stripe のガイドに従ってください。

影響: 正しいホワイトリスト登録が解決したもの

Sucuri ファイアウォール内で Stripe の IP をすべて構成し、Webhook エンドポイントの WAF ルールの動作を調整した後、問題は完全に解消されました。 Webhook は即座に認識されるようになり、Stripe の再試行メカニズムはアクティブではなくなり、イベントは失われませんでした。

ワークフローとユーザーエクスペリエンスの観点から —

顧客には支払い確認の遅延が表示されなくなりました。
失敗したサブスクリプションに関するサポートチケットは削除されました。
新しいユーザーアカウントの作成などのバックエンドの自動化が再び確実に機能しました。

自動化に関する注意事項

Stripe の IP リストは進化する可能性があるため、四半期ごとのカレンダーリマインダーを設定して更新を確認することをお勧めします。残念ながら、Sucuri は API ベースのホワイトリスト自動化を提供していないため、プロセスは手動のままです。 Webhook 配信の失敗を再度回避したい場合は、これについて積極的に行うことが重要です。

最終的な考え

Sucuri WAF は、Web プロパティを安全に保つための強力なツールですが、確実なセキュリティシステムはありません。特に Stripe のような正規のサービスでの誤検知は、実際のビジネス上の摩擦を引き起こす可能性があります。適切な IP と WAF ルールのカスタマイズを少し行うことで、支払い処理を合理化して安全に保つことができます。

覚えておいてください:セキュリティは、機能を犠牲にして実現する必要はありません。慎重に構成すれば、両方の調和を保つことができます。