※本ブログは米国時間2025年5月15日に公開されたA10本社ブログの日本語訳です。原文はこちらからご覧ください。

アプリケーション プログラミング インターフェース(API)は、現代のソフトウェア開発の基盤です。豊富な機能と相互運用性をプログラマが製品開発時に利用できるようにし、開発プロセスを簡素化します。既存の機能をゼロから開発する必要がなく、時間とリソースを節約できます。

しかし長年にわたり、攻撃者はAPIを介してウェブサイト、サーバ、その他のインフラにアクセスし、データを盗むための様々な方法を模索していました。APIエンドポイントが正しく実装されていなかったり、設定ミスがあったり、その存在が忘れられていたりすると、インフラ全体がサイバー攻撃に対して脆弱になる可能性があります。多くのAPIは、個人を特定できる情報(PII)や知的財産(IP)情報などの機密データを管理しているため、攻撃者にとって特に魅力的な標的となってしまいます。

あらゆる企業がAPIの脅威を感じています。Google、Instagram、Clubhouse、British Airwaysといった業界大手企業でさえ、API侵害を経験しています。API侵害は大きなリスクであり、企業はAPIのセキュリティ対策を講じることが不可欠といえます。本ブログでは、一般的なAPIリスクと、それらからAPIを保護する方法について見ていきましょう。

一般的なAPIリスクとは？

APIに関連するリスクには、機密性の高いユーザデータを漏洩させるデータ侵害や不正アクセスがあります。不正アクセスは、そのシステムが管理している内容に応じて、様々な被害につながる可能性があります。機密情報を管理するAPIは、悪用される可能性が高くなります。攻撃者がAPIを悪用する方法は複数ありますが、最も一般的なものを幾つか挙げます。

1. 壊れたオブジェクト認可(Broken Object Level Authorization: BOLA)の悪用

オブジェクトレベルの認可とは、APIに実装された制御メカニズムであり、ユーザが認可されたオブジェクトにのみアクセスできるようにすることです。アクセス制御には、セッショントークン、セッションキー、時間ベースのパラメータ、複雑な環境ではこれら以上の動的な制御など、さまざまな方法があります。

エンドポイントがオブジェクトIDを受け取り、そのオブジェクトに対してアクションを実行するすべてのAPIは、オブジェクトレベルの認証を実装する必要があります。オブジェクトレベルの認証が破られると、攻撃者はエンドポイントのAPIリクエスト内で送信されたオブジェクトのIDを不正に操作し、アクセスすべきではない機密データにアクセスできるようになってしまいます。

2. サービス拒否(DoS)攻撃やボットによるその他の攻撃

サービス拒否(DoS)攻撃は、サーバまたはネットワークへの正常なトラフィックフローを妨害、または妨害しようとする攻撃者が、サーバのリソースを圧倒するような大量のリクエストを送付することで発生します。分散型DoS(DDoS)攻撃では、攻撃者は多数の(場合によっては数百万台にも及ぶ)侵害されたデバイスを、多くの場合様々な地域に分散して利用し、ターゲットにリクエストを送信します。これらの侵害されたデバイスはボットと呼ばれ、複数のボット間の接続はボットネットと呼ばれます。

DDoS攻撃では、各ボットは通常のシステムユーザと同様に、サーバアドレスにリクエストを送信します。しかし、これらのリクエストは同時に送信され、多くの場合単一のターゲットに向けられているため、ターゲットのサーバリソースは圧迫され、サービス、ウェブサイト、またはネットワークの速度が異常に低下し、場合によっては利用不能に陥ることがあります。

接続速度が遅くなること以外にも、次のような兆候は、ウェブサイトがDDoS攻撃を受けている可能性を示唆しています。

  • 1つのIPアドレス、または1つのアドレスレンジ内の複数IPアドレスからの大量のトラフィック
  • ウェブブラウザのバージョン、デバイスの種類、地理的特徴など、類似したプロファイル特性を持つエンティティからの大量のトラフィックがある
  • 1ページ、または１つのエンドポイントへのリクエストが、前例のないほど急増する
  • 特定の間隔で、または日中であっても通常とは異なる時間帯、特に休日や週末に、トラフィックが不審に急増する

DDoS攻撃だけではデータが漏洩することはないかもしれませんが、ユーザがプラットフォームを利用できなくなる可能性があります。このことは、多くの場合はコストのかかるダウンタイムや収益の損失につながります。最も一般的なDDoS攻撃は、アプリケーション層攻撃、プロトコル攻撃、そしてウェブサイトやAPIエンドポイントに対するボリューム攻撃です。

悪意あるボットによる攻撃が、これまで以上に多様な形態をとっていることに注意が必要です。例えば、クレデンシャルスタッフィング攻撃では、ログインページへのボットからのリクエストが急増し、既知のログイン情報のデータベースを自動的に巡回してアクセス権限を確認します。また、攻撃者は従来の単純な検出ルールを回避し、防御を妨害するために行動を学習・進化させています。例えば、特定のサイトへのDDoS攻撃でセキュリティチームの注意を逸らしながら、ノイズに埋もれてしまう別の脆弱性を悪用するといったことが挙げられます。

3. ページネーション攻撃

ページネーションとは、情報を複数のページに分割する手法です。APIはユーザにエンティティのリストを提供するのが一般的です。クライアントは通常、そのリストをフィルタリングしてページネーションし、必要な数のエンティティのみを返します。ページネーション攻撃では、攻撃者はこれらの制限を回避し、そこに保存されている大量の機密情報を公開します。

4. 安全でないAPIキーの生成

多くの開発者は、APIのセキュリティを確保するためにAPIキーを使用します。APIキーは、侵入があった場合にAPIを追跡・保護するのに役立つ一意の識別子です。システム管理者はAPIキーを通じて、不審な動作を特定し、ユーザのアクセスをブロックすることができます。攻撃者は巧妙な方法でAPIキーを不正に生成し、侵害されたデバイスを攻撃元として利用するなどしてDDoS攻撃を実行する可能性があります。

5. 不適切なサーバセキュリティ

サーバセキュリティとは、サーバが保持するデータを保護するための対策を指します。サーバを保護する最も効果的な方法の一つは、Secure Sockets Layer(SSL)やTransport Layer Security(TLS)などのサーバセキュリティ証明書を使用することです。これらのプロトコルは、スクランブル化により機密データを暗号化します。サーバによって保存または送信される情報が適切に保護されていない場合、攻撃者はAPIキーにアクセスし、DoS攻撃を仕掛ける可能性があります。

6. インジェクション攻撃

API侵害は、多くの場合、インジェクション攻撃によって発生します。インジェクションは、攻撃者がAPIに悪意のあるコードやコマンドを送り込むことです。一旦システムに侵入すると、その送り込まれたコードやコマンドがDoS攻撃の実行やAPIをホストするサーバの乗っ取りに利用される可能性があります。インジェクションは通常、クライアントから提供されたデータがフィルタリング、検証、サニタイズされていない場合に発生します。

API保護のベストプラクティス

API保護は、サイトとサーバの整合性を確保します。APIが管理するデータの種類に応じて、導入すべきセキュリティ対策が決まります。API保護のベストプラクティスを以下にてご紹介します。

1. APIのインベントリ化(在庫管理)

組織には多数の公開APIが存在する場合がありますが、その数を把握していなければ、APIのセキュリティを確保することはできません。すべてのAPIをインベントリ化し、管理計画を立てることが推奨されます。管理計画の不在は、インフラのセキュリティ上の欠陥につながることがあります。

2. ロバストなAPIアクセス制御の採用

認証と認可の制御は、APIへのアクセスを制御するための最適な方法の一つです。APIの認証方法は数多くありますが、最も推奨されるのはOAuthです。OAuthはトークンベースの認証フレームワークであり、サードパーティのサービスがユーザの認証情報を公開することなく情報にアクセスできるようにします。

より細かな制御を行うには、例えばトークンの有効期限を24時間などに設定すべきです。こうすることで、APIはユーザの再認証を行い、万が一セキュリティ侵害が発生した場合でも、攻撃者がリソースにアクセスできる時間を限定することができます。

3. Webアプリケーションファイアウォール(WAF)の導入

ウェブアプリケーションファイアウォール(WAF)は、インターネットとサーバを仲介する役割を果たします。WAFには、安価でシンプルな防御機能から、堅牢なエンタープライズグレードの保護機能まで、様々な種類があります。最新のWAFは、ウェブアプリケーションおよびAPI保護プラットフォーム(WAAP)と呼ばれ、クラウドやオンプレミスを含むあらゆるインフラ上のウェブアプリケーションとAPIを介したすべてのレイヤー7トラフィックに対し、インライン ブロックによる保護を提供できます。

WAFは、フィルタリング、監視、検知によって、攻撃に即座に対応する必要があります。悪意あるトラフィックがサーバに到達しないよう、自動的にブロックすることも求められます。また、WAFはDDoS攻撃が発生した場合にも役立ち、レート制限の適用が必要になった際に迅速にポリシーを変更できます。さらに、APIの不審な使用を識別、追跡、ブロックする機能も備えている必要があります。

WAFを選ぶ場合には、次の点を考慮してください。

  • そのWAFによって、どのような脅威から守られるのでしょうか?
  • そのWAFは、フルブロッキングモードで実行できますか？ 事前に評価(PoC)を実施すべきです。
  • そのWAFは、デプロイメントや更新、ルール調整のために、どれくらいの稼働が必要ですか?
  • そのWAFプラットフォームはマネージドサービスとして利用可能でしょうか、サポートは十分に受けられるでしょうか?
  • そのWAFは、アプリケーションとAPI全体で必要なすべてのトラフィックを保護できますか?

4. レート制限の導入

レート制限は、一定の閾値を超えるリクエストを拒否します。API呼び出しの方法と頻度を制限することで、過剰なトラフィックを抑制し、DDoS攻撃からサイトを保護することができます。

5. 脆弱性の特定

APIのセキュリティを強化するには、開発者は攻撃者の視点に立ち、APIライフサイクルのどの部分が攻撃に対して脆弱であるかを理解する必要があります。また、攻撃を検知・阻止できるようにAPIを構造化することも重要です。

6. APIセキュリティを優先すること

APIは、ソフトウェア成果物のように扱われるべきです。つまり、アプリケーションと同様に、計画、脅威モデリング、開発、テスト、セキュリティ保護、そしてステージングを行う必要があります。

7. TLS暗号化

サーバが保持・管理するすべてのデータは、保存時も転送時も暗号化する必要があります。保存中のデータは多くの場合、対称暗号化で暗号化されますが、転送中のデータはSSL(現在は廃止)の後継技術であるTLSで暗号化されます。TLSは、攻撃者によるデータの閲覧や改ざんを防ぎ、通信が正規のサイトからのみ行われることを保証します。

8. ゼロトラストモデルを採用すること

従来、ネットワークには境界があり、その内側と外側に要素が存在していました。境界内の要素は「信頼」され、外側の要素は信頼されませんでした。この構成はネットワークを外部の脅威から保護しますが、内部からの攻撃に対しては脆弱なままです。

この脆弱性を軽減するには、すべてのユーザとアプリケーションを認証・認可する必要があります。簡単に言えば、ゼロトラストAPIを採用することです。さらに、APIの脆弱性は他の関係者のアクセスレベルと相関するため、APIはユーザまたはサービスがその役割を果たすために必要最小限の権限のみを付与する必要があります。

9. 必要以上の情報を公開しないこと

APIは常に、クライアントの機能を実行するために必要な情報のみを返し、残りの情報はエンドポイントでフィルタリングするようにしてください。一部のAPIでは、データのフィルタリングをユーザインタフェイスに委ねているため、必要以上の情報が公開されてしまうことがあります。さらに、攻撃ベクトルを絞り込むために、APIの使用を簡素化する他の方法も検討してください。

10. クライアントから取得したデータを検証すること

エンドポイントからの入力は、別のエンドポイントに渡す前に必ず検証、フィルタリング、サニタイズしてください。これにより、ウェブサイトやインフラをSQLインジェクションなどの攻撃から保護できます。

■関連情報
The Buyer's Checklist for API Protection Solutions (英語)