API には攻撃を遅らせるようなインターフェースレイヤーが存在しません。攻撃は瞬時に発生し、一般的なモニタリングシステムが警告を発するより前にその損害が積み上がってしまいます。API に関わるセキュリティインシデントは 2024 年から 2025 年にかけて対前年比 32% も増加しました。

ここでは、実際の API 不正の例、サービスとしてのソフトウェア (SaaS) および AI プラットフォームでよく見られるパターン、そしてリアルタイムの API 不正利用防止戦略について見てみましょう。

主なポイント

• 自動化されたスクリプトはバックエンドのエンドポイントを直接攻撃できるため、標準的なモニタリングシステムが攻撃を検出する前にコストのかかる深刻な問題が引き起こされる恐れがあります。

• レート制限、ボット管理、デバイスシグナル、適応型認証を組み合わせた多層防御は、単一の制御を単独で使用するよりも効果が高くなります。

• クレデンシャルスタッフィングと新規アカウントの不正登録は、同一の攻撃チェーンにおける相互に関連した段階です。したがって、ログインと登録の防御は、同時に設計・監視する必要があります。

登録システムおよびトライアルシステムにおける API の不正利用とは

API の悪用とは、スクリプトが、本来それらのエンドポイントが対応するはずのユーザーインターフェイス (例: 登録 API、決済 API、トライアルのプロビジョニングフローなど) を経由せずに、バックエンドのエンドポイントを直接攻撃することを指します。偽アカウントが API トークンや推論クレジットのバッチを要求するごとにプロビジョニングの費用がかかります。

SaaS および AI プラットフォームにとってリアルタイムの API 不正利用防止が重要である理由

自動化された API の不正利用にかかる時間はわずか数秒です。それは、日次のセキュリティレポートで異常が判明する頃には、被害が深刻化しているということです。トライアルの登録時にシステムが第三者のモデル API を計算・実行する仕組みの場合、偽アカウント 1 件ごとに実質的な変動費が発生することになります。1 分間に 100 件の登録を行う攻撃が 20 分間続くと、2,000 件の不正アカウントが作成されます。これらの 1 つひとつのアカウントがバックエンドでのリソース割り当てを連鎖的に引き起こす恐れがあります。

大量の不正アクセスはエンドポイントに多大な負荷をかけるため、サービスの質が低下し正当なユーザーにまで悪影響を及ぼします。登録フローが遅延して認証処理が滞留し、さらにデータベースの書き込み能力が限界に達します。攻撃パターンを 5 分で特定し自動でブロックする防御策と、24 時間後にダッシュボードで被害を確認する仕組みとでは根本的な価値が異なります。

SaaS および AI プラットフォームでよく見られる API 不正利用のパターン

API の攻撃者は、意図的に公開されたエンドポイントを悪用する傾向があります。このような悪用パターンは、SaaS および AI プラットフォーム全体で一貫して見られるものです。

• 自動化されたアカウント作成: スクリプトが、使い捨てのメールアドレスを使用して偽アカウントを生成します。それによって登録 API を繰り返し呼び出し、トライアルファーミング、評判の操作、または後の転売のためにアカウントプールを構築します。

• 無料トライアルファーミング: 攻撃者は、トライアルクレジットやコンピューティングの割り当てを直接標的にします。無料トライアルに推論クレジットが含まれる AI プラットフォームでは、数百のアカウントをファーミングすることで大きな成果が得られる可能性があります。

• ログインエンドポイントに対するクレデンシャルスタッフィング: 攻撃者は、データベースから流出したユーザーネームとパスワードのペアを試行します。たとえ成功率が低くても、膨大な数のペアを試せば多くのアカウントが侵害される可能性があります。

• レート制限の回避: 分散型攻撃は、インターネットプロトコル (IP) アドレスごとのしきい値を下回るように、何千もの IP にリクエストを分散させます。IP のみで追跡するレート制限機能では、1 万件の IP に毎分 2 件のリクエストを行うといったボットネットを見逃してしまいます。

• 認証エンドポイントの悪用: ショートメッセージ (SMS) やメールによる確認エンドポイントは、攻撃者にとって魅力的な標的になります。これらを不正に使用することで、特定のアカウントがシステム内に存在するか否かが判明したり、SMS 送信用予算を使い果たしたりする恐れがあります。

• トークンスクレイピング: アカウントをファーミングまたは侵害した後、スクリプトは API キー、セッショントークン、または OAuth 認証情報を収集して、転売したりバックエンドに対する攻撃で使用したりします。

API の不正利用と、クレデンシャルスタッフィングおよび新規アカウントの不正登録はどのように関連しているのか

攻撃者は、侵害されたデータベースから流出したクレデンシャルペアを使ってログイン API に対するテストを行います。ログインに成功すれば既存のアカウントに不正にアクセスできます。しかし、多要素認証の導入やユーザーによるパスワードの使い回しがなくなれば、スタッフィングの成功率が低下します。そうすると、同じ攻撃者は今度は標的を新規登録のエンドポイントに移します。

特にトライアル用リソースが利用可能で本人確認が簡略化されている場合など、新規アカウントを作成する方が既存アカウントを侵害するよりも簡単な場合が多くあります。ログインの防御が強化されると、新規登録のエンドポイントの方が抵抗の少ない経路になります。攻撃者はトライアルファーミング、スパムキャンペーン、紹介プログラムの悪用などを目的として大量に作成したアカウントを利用したり、それらを寝かせたアカウントのプールとして転売したりすることもあります。中には将来の利用を見越してアカウントを作成し、すぐには使用しない者もいます。このような攻撃者は初期の不正利用チェックをやり過ごしてからアカウントを有効にします。

攻撃者はログインエンドポイントを調べてアカウント構造やエラーメッセージ、レート制限の挙動を学習することがあります。攻撃者は登録フローに移行する際にこうした情報を使用します。すなわち、ログイン防御と登録防御を別々に設計すると、組織的な攻撃によって見つかりやすい間隙が生じるということです。

Stripe Radar は、決済フロー内でこうした問題に対処します。それにより、カードの動作、デバイスシグナル、およびアカウントの履歴をリンクさせることで、単一のシグナルだけでは問題がないように見える不正利用が明らかになります。攻撃チェーン全体にわたって相互に関連するシグナルを見ることで、エンドポイントレベルの監視では完全に見逃されてしまう一貫した状況を理解することができるのです。

リアルタイムの API 不正利用防止戦略とは

単一の制御で API の悪用を阻止することは不可能です。システムを防御するアーキテクチャは多層化する必要があります。

防御策には次のような手段を含める必要があります。

• レート制限: IP ごとの制限は最低限必要な対策です。また、アカウント、デバイスのフィンガープリント、メールドメイン、および行動セッションごとのレート制限も設定する必要があります。そうすることで、IP のしきい値を下回る分散型攻撃でも、スタックの他の場所で上限に達することになります。

• ボット管理: 専用のボット管理ツールを API の前段に配置し、トラフィックがアプリケーション層に到達する前に分類を行います。これらのツールは、トランスポート層セキュリティ (TLS) フィンガープリント、HTTP/2 の動作、リクエストのタイミング、ヘッダーの異常といったシグナルを用いてボットを識別します。

• デバイスと ID のシグナル: プロビジョニングを行う前に、デバイスのフィンガープリント、IP レピュテーションスコア、および ID シグナルを収集します。メールアドレスの品質も強力なシグナルです。

• 適応型認証: リスクの高いシグナルに応じてメール確認、電話認証、または手動審査を実行する段階的認証は、正規のユーザーを足止めすることなく不正利用から保護します。

• 異常検知: 通常時のエンドポイントトラフィックのベースラインを設定し、そこから逸脱した際にアラートが飛ぶように設定します。作成直後に他のアクティビティを行わずに即座にトライアルプロビジョニングのエンドポイントを呼び出すようなアカウントは監視対象とする価値があります。

チームがリアルタイムで API の不正利用を監視する方法

リアルタイムで API の不正利用を監視するには、適切なシグナルを探す必要があります。API の不正利用によく見られる次のような兆候に注意しましょう。

• レスポンスコード別のリクエスト数: 登録エンドポイントにおける新規アカウント作成の急増は攻撃のシグナルです。エンドポイントごとにトラフィック量を追跡しそれをレスポンスコードで分類することで、エラーの発生だけでなく、作成の成功のピークも可視化されます。

• 認証エンドポイントにおけるエラー率の変化: ログインエンドポイントにおける 401 Unauthorized エラーなど、エラーコードのレスポンスの急増は、多くの場合、クレデンシャルスタッフィングの前兆またはそれに付随して発生するものです。

• 新規登録アカウントが使用するメールドメインの分布: 正規のユーザーはさまざまなメールを使用します。約 40% が Gmail、20% が企業ドメインで、残りはさまざまです。不正利用が発生すると、その分布が使い捨てドメインに急激にシフトします。

• 登録から最初のアクションまでの時間: 正規のユーザーは製品をブラウズします。それに対してボットは登録を完了した時点で停止するか、特定のプロビジョニングエンドポイントをすぐに呼び出します。このような行動の違いがコホートレベルで検出された場合、有力なシグナルになります。

• 地理的分布および ASN 分布の変化: データセンタープロバイダーや住宅用プロキシネットワークなど、特定の自律システム番号 (ASN) からのトラフィックが急激に増加するのは警告の兆候です。

Stripe Radar でできること

Stripe Radar は、Stripe のグローバルネットワークのデータで学習した AI モデルを使用して不正利用を検知・防止するツールです。最新の不正傾向に応じてモデルを常に更新し、不正利用の手口が進化してもビジネスを守ります。

Stripe はこのほか、Radar for Teams も提供しています。ユーザーは自社ビジネス特有の不正シナリオに対応するカスタムルールを追加でき、高度な不正分析情報にアクセスできます。

Radar は以下のことに役立ちます。

• 不正利用による損失の防止: Stripe は年間 1 兆ドルを超える決済を処理しています。この規模だからこそ、Radar は不正利用を正確に検知・防止し、コスト削減に貢献します。

• 収入の向上: Radar の AI モデルは、実際の不審請求の申し立てデータ、顧客情報、閲覧データなどをもとに学習しています。これにより、Radar はリスクの高い取引を特定し、誤検知を減らして、収入向上に貢献します。

• 業務効率化: Radar は Stripe に組み込まれており、設定のためのコーディングは一切不要です。1 つのプラットフォームで不正利用への対応状況の監視やルールの作成などができるため、業務効率が向上します。

Stripe Radar について詳しくはこちらをご覧ください。または今すぐ始める場合はこちら。