現代のインターネットの多くは、APIに依存して機能しています。APIセキュリティとは、APIを攻撃やデータ漏えいから保護するプロセスです。
この記事を読み終えると、以下のことができるようになります。
関連コンテンツ
是非、Cloudflareが毎月お届けする「theNET」を購読して、インターネットで最も人気のある洞察をまとめた情報を入手してください！
記事のリンクをコピーする
アプリケーションプログラミングインターフェース（API）は、あるソフトウェアが別のソフトウェアとやりとりするための仕様です。プログラムまたはアプリケーションにAPIがあれば、外部のクライアントがそのプログラムに対してサービスを要求することができます。
APIセキュリティとは、APIを攻撃から守るためのプロセスです。アプリケーション、ネットワーク、サーバーが攻撃の対象になり得るのと同様に、APIもさまざまな脅威の犠牲になる可能性があります。
APIセキュリティは、Webアプリケーションセキュリティの中核となる要素です。現代のほとんどのWebアプリケーションは機能するためにAPIを使用しており、APIは外部からアプリケーションにアクセスすることを可能にすることで、アプリケーションにさらなるリスクを生み出しています。例えるなら、オフィスを一般に公開している企業のようなものです。同様に、APIは部外者がプログラムを使用することを可能にするため、APIサービスのインフラストラクチャにさらなるリスクをもたらします。
APIセキュリティ対策は、これらのリスクやその他のリスクの軽減にも役立ちます。
強力な認証・認可対策により、データの漏洩を防ぎ、許可されたクライアントのみがAPIリクエストを行うことが保証されます。DDoS攻撃対策とレート制限により、DDoS攻撃をシャットダウンすることができます。スキーマの検証とWeb アプリケーションファイアウォール（WAF）を使用することで、脆弱性の悪用をブロックすることができます。
レート制限は、個人が特定の時間枠の中でアクションを繰り返すことができる回数に上限を設定します。APIクライアントが許可されたリクエストの数を超えた場合、レート制限は一定期間、そのクライアントからの更なるリクエストを破棄またはブロックします。
DDoS軽減は、DoS攻撃やDDoS攻撃を阻止するのに役立ちます。DDoS攻撃は、攻撃者は短時間に大量のリクエストでAPIを圧倒しようとします。多くの場合、これらのリクエストは複数の異なる送信元ソースからやってきます。
レート制限とDDoSの軽減は、いくつかの理由からAPIにとって非常に重要です。
脆弱性を悪用するには、悪意のあるAPIリクエストが、設計者が意図していない方法でAPIを応答させるように構成されている必要があります。API開発者がそのような悪意のあるリクエストをブロックする方法はいくつかあります。その中でも特に知っておくべき重要なものは、以下の2つです。
APIのスキーマには、APIがどのようなリクエストを受け、どのようなレスポンスを返すべきかといった、APIに期待される振る舞いが記述されています。このスキーマに従わない無効なリクエストは、APIに予期せぬ振る舞いをさせ、データ漏洩を引き起こす可能性があります。スキーマの検証によって、無効なリクエストとレスポンスが特定されます。無効なレスポンスをブロックすることで、API開発者はある種の攻撃を回避し、データ漏えいを防ぐことができます。
WAFは、従来のファイアウォールと同様に、一部のネットワークリクエストとレスポンスをブロックし、それ以外を許可することで機能します。これは一連のルールに基づいて行われ、リクエストやレスポンスがルールに違反する場合（またはルールに適合する場合）にブロックされます。WAFは、APIやWebアプリケーションの前衛に設置されてHTTPトラフィックを監視します。
脆弱性を狙ったリクエストやレスポンスのパターンをブロックするWAFルールを設定することが可能です。また、WAFルールは、特定のIP アドレスからのリクエストをブロックすることができ、bot攻撃などを阻止することができます。
認証により、APIリクエストが正当なソースから来たものであることが保証されます。認証によって、リクエストしたクライアントに要求されたデータを取得する権限があるかどうかがAPIサーバーに伝えられます。
アリスがAPIを構築し、ボブがアリスのAPIを利用するWebアプリケーションを構築したとします。ボブのアプリケーションがアリスのAPIにAPI リクエストを送る際に、ボブはリクエストに「this is from Bob」というラベルを付けます。これによりボブのリクエストが認証され、アリスの API サーバーがそのリクエストを正当なものとして扱うことができるようになります。
また、アリスのAPIサーバは、ボブがどのような権限を持っているかもチェックします。もしボブのリクエストが、アリスのAPIに「Bob can see this」と表示されているデータに対するものであれば、サーバーはそのリクエストに応えます。しかし、アリスの API に「not for Bob」というラベルのついたデータセクションがあり、リクエスト者がボブである場合、サーバーはこのデータに対するリクエストには応えません。これが認可が重要な理由です。
（実際には、ボブはAPIリクエストに「this is from Bob」というラベルだけでなく、キーや他の認証形式も付加します）
APIの認証方法にはいくつかあります。最も一般的なものには以下のものがあります。
クライアントには、クライアントとAPIサービスだけが知っている一意の文字列であるキーが割り当てられます。このキーは、各APIリクエストに付加されます。APIサーバーはAPIリクエストを受け取ると、それが認証されたクライアントからのものであるかどうかを確認するために、このキーをチェックします。
この認証方式の欠点は、キーが盗まれた場合、攻撃者はそれを使用して正規のクライアントになりすまし、さまざまな攻撃を仕掛けることができてしまうことです。Transport Layer Security（TLS）のような暗号化プロトコルを使用して、APIへのリクエストとレスポンスを暗号化することが重要になります。こうすることで、キーがインターネット上を行き来する際に平文でさらされることはありません。
APIリクエストでは、一般的なユーザー名とパスワードの認証情報を使用するHTTP認証と呼ばれる方法を用いることができます。HTTP認証では、ユーザー名とパスワードがエンコードされ、すべてのAPIリクエストのHTTPヘッダーに追加されます。サーバーは、これらの資格情報を、許可されたクライアントの資格情報と照合して、リクエストを認証することができます。
この方法は、一般的なパスワードに関連するあらゆる課題（紛失、漏えい、盗難、推測、信頼できない相手との共有など）を含んでいます。また、パスワードはクレデンシャルスタッフィングやブルートフォース攻撃などの対象になります。
APIサーバーは、クライアントから直接認証を要求する代わりに、OAuthプロトコルを使用して、信頼できる認証サーバーから認証トークンを取得することができます。APIを利用するために、ユーザーはAPIに直接ログインするのではなく、サードパーティのサービスにログインします。ユーザー名とパスワードによるアプローチと同様に、この認証方法は、クレデンシャルスタッフィングやその他の攻撃に対して脆弱性があります。
TLSは、Webページを読み込む際にクライアントとサーバーの間に暗号化された認証済みの接続を作成するための暗号化プロトコルです。また、TLSはAPI接続の両端を検証して認証することができます。
相互TLS認証（mTLS）では、クライアントとサーバーの両方がTLS証明書を持ちます。これらの証明書を使用してお互いを認証し、パスワードや他の認証方法に依存することなく、両者が主張する人物であることを確認します。
しかし、mTLSは実装が難しい場合があります。すべてのAPIエンドポイントとクライアントには正規のTLS証明書が必要ですが、これを適用・維持するのは困難な場合があります。
Cloudflare API Gatewayは、一般的なAPIセキュリティリスクから保護するために、1つのダッシュボードから複数のAPIセキュリティ機能を使用できるようにしています。API Gatewayには以下のような機能があります：
API GatewayまたはAPIセキュリティソリューションの詳細は、リンクをご覧ください。