OWASP API トップ10 (2023): テストと修正を含む完全ガイド

APIは現代のソフトウェアに不可欠ですが、固有のセキュリティリスクも伴います。2020年には91%の組織がAPIセキュリティインシデントを報告しており、攻撃はますます頻繁かつ深刻になっています。OWASP APIセキュリティ トップ10は、フレームワークとして、オブジェクトレベル認証の不備（BOLA）、過剰なデータ公開、サーバーサイドリクエストフォージェリ（SSRF）などの脅威に対してAPIを保護するために設計されています。

主要なポイント：

• APIは現在Webトラフィックの83%を占めており、主要な攻撃対象となっています。

• APIセキュリティ侵害の平均コストは488万ドルで、2023年のT-Mobile侵害では3,700万人のユーザーに影響しました。

• OWASPのフレームワークは、認証の不備、セキュリティの設定ミス、レート制限の失敗などのAPIリスクのトップを強調しています。

APIを保護するために：

• 強力な認証（OAuth 2.0、MFA）と認可（RBAC）を使用します。

• 入力を検証し、サーバーサイドフィルタリングを実施し、データ公開を制限します。

• レート制限を適用し、異常についてトラフィックを監視します。

• Qodexなどのツールを使用してAPIをOWASP基準に対して定期的にテストし、脆弱性検出を自動化します。

OWASP APIセキュリティ トップ10コース - Webアプリケーションのセキュリティ確保

OWASP APIセキュリティ トップ10脆弱性の解説

OWASP APIセキュリティ トップ10の各リスクの詳細を把握することは、機密データを保護しAPIを安全にするために不可欠です。これらの脆弱性は、システムを侵害し個人情報を公開する可能性のある一般的な攻撃手法を示しています。主要なリスクを詳しく見ていきましょう。

OWASP API トップ10: 2019年から2023年で何が変わったか

OWASPの2023年更新では、本番環境でのAPIへの実際の攻撃手法を反映するためにカテゴリーを統合・再編成しています。API3: オブジェクトプロパティレベル認可の不備（BOPLA）は、2019年の過剰なデータ公開とマスアサインメントの両方をフィールド・プロパティレベルでカバーするようになりました。リソース消費の無制限は「リソースとレート制限の欠如」を置き換え、SSRFが独自のカテゴリーとなり、安全でないAPIの使用は「不十分なログと監視」を置き換えています。これらの変化を理解することで、チームはテスト計画とコントロールを最新化できます。

1. オブジェクトレベル認可の不備

オブジェクトレベル認可の不備（BOLA）は、APIが特定のオブジェクトやリソースへのアクセス権限をユーザーが持っているかどうかを確認できない場合に発生します。この欠陥は、オブジェクト識別子に紐付けられたエンドポイントを公開することでリスクを高めます。

この問題は多くの場合、認可チェックの不備から生じます。APIはユーザーがアクセスを許可されているかを検証せずに、クライアントが提供するオブジェクトIDに依存します。リクエストの正当性を確認する代わりに、APIはリクエストが正当であると仮定します。

2021年のPeloton APIの欠陥の注目すべき例では、ユーザーが他のユーザーのアカウント詳細を見ることができ、個人情報が公開されました。これは、このような見落としがユーザーのプライバシーをどのように危険にさらすかを示しています。

攻撃者はリクエスト内のオブジェクト識別子を操作して、他のユーザーのリソースにアクセス、変更、または削除します。これは特に医療や金融記録などの規制されたデータについて、深刻なプライバシー侵害とコンプライアンス問題につながる可能性があります。

オブジェクトプロパティレベル認可の不備のリスク

APIがオブジェクトプロパティレベルで適切なチェックをスキップすると、機密データが漏れたり、悪意を持った相手の手に渡ったりする可能性があります。特定のオブジェクト内のフィールドへのアクセスや変更の権限があるかを検証する代わりに、多くのAPIは誤って受信リクエストを信頼してしまいます。

その結果、攻撃者は本来アクセスできてはいけない情報を閲覧または変更する可能性があります。たとえば、ユーザープロファイルの奥深くに隠れているメールアドレス、アカウント設定、機密財務詳細などです。一見無害に見えるエンドポイントでも、特定のオブジェクトプロパティを標的としたリクエストを巧みに作成できる人にとっては宝の山となり得ます。

これらの検証のギャップを放置すると、次のような事態につながります。

• 過剰なデータ公開によるユーザーの個人データの偶発的な漏洩

• マスアサインメントによる保護されたプロパティへの不正な編集

• 特に規制されたデータ（医療記録など）に関するコンプライアンス上の問題

• 見落とされたAPIエンドポイントを悪用しようとする攻撃者への招待状

最終的に、プロパティレベルのセキュリティを見落とすことは、単に個人のプライバシーを脅かすだけでなく、API エコシステム全体を損なう可能性があります。

BOLAに対するテストとゲートの方法

クライアントからオブジェクトIDが来る場所にはどこでもサーバーサイドのパーミッションチェックを追加します。CIでは、クロステナントID、不足しているスコープ、過去のオブジェクトIDを試みるネガティブテストを含め、403以外の応答でビルドを失敗させます。リクエストログを使用して実際の悪用試行から拒否リストのテストケースを自動生成します。

• オブジェクトオーナーをロードしてsub/tenant_idと比較するポリシーチェッカー（ミドルウェア）を追加します。

• 列挙を減らすために連番IDをマスク・ローテーションします（不透明なGUIDを推奨）。

• BOLAテストでマージをゲートし、PR可視性のためにJUnitとして保存します。

2. 認証の不備

認証は不正アクセスに対する最初の障壁ですが、認証の不備によりAPIが脆弱になる可能性があります。これらの欠陥は、ユーザーアイデンティティの適切な検証に失敗する弱い、設定ミスの、または安全でない認証システムから発生します。

「認証メカニズムは、すべての人に公開されているため、攻撃者にとって格好のターゲットです。」- OWASP

一般的な問題には、弱いパスワード、多要素認証の欠如、ブルートフォース攻撃に対する不十分な保護が含まれます。多くの組織は安全なトークン検証とセッション管理にも苦労しており、悪用可能なギャップを残しています。

例えば、2018年のUSPS APIの欠陥では、認証されたユーザーが適切なチェックをバイパスできることにより、6,000万人のユーザーのアカウントデータが公開されました。

認証メカニズムが失敗すると、攻撃者はユーザーになりすまし、機密データにアクセスし、不正なアクションを実行できます。この脆弱性はしばしばより高度な攻撃への入り口となり、強力な認証プロトコルの必要性を強調しています。

3. 過剰なデータ公開

過剰なデータ公開は、APIがサーバーサイドコントロールの代わりにクライアントサイドフィルタリングに依存して、必要以上のデータを送信するときに発生します。

「APIはデータフィルタリングを実行するためにクライアントに依存しています。」- OWASP

開発者はしばしば、さまざまなデータニーズを持つ複数のクライアントに対応するために完全なデータセットを返し、クライアントが不必要な情報をフィルタリングすることを期待します。このアプローチは、ネットワーク越しに過剰なデータを送信するリスクを見落としています。

例えば、TwitterのAPIの欠陥により、攻撃者が個人情報のデータセットを収集し、ハッカーフォーラムで販売されました。

この脆弱性は、機密データを不必要に公開しないためのサーバーサイドフィルタリングの重要性を示しています。

オブジェクトプロパティレベル認可の不備: より安全なペイロードバインダー

許可リストバインディングによるマスアサインメントの防止
ほとんどのBOPLAバグは、フレームワークがリクエストボディ全体をモデルにバインドするときに発生します。書き込み可能なフィールドのサーバーサイド許可リストと、機密プロパティ（例: role、plan、isAdmin）を変更する前の明示的なロールチェックを実施します。

これをレスポンスのスキーマ検証と組み合わせて、偶発的なフィールドの漏洩を防ぎます。

4. セキュリティの設定ミス

セキュリティの設定ミスは、APIセキュリティにおいて広範ですが防止可能な問題です。APIがデフォルト設定、不足しているパッチ、または不要な機能によって脆弱なままになるように不適切に設定されている場合に発生します。

問題は多くの場合、環境全体の不完全なセキュリティ強化、古いシステム、またはデプロイメント中のベストプラクティスへの準拠不足から生じます。多くの組織は開発、ステージング、本番環境全体で一貫した設定を維持するのに苦労しています。

2017年には、SVR TrackingのAPIの設定ミスにより50万台以上の追跡デバイスのデータが公開されました。最近2024年には、FleetSecureのX-Api-Versionヘッダーの設定ミスにより、攻撃者が悪意のあるJNDIルックアップを注入し、不正アクセスとコマンド実行が可能になりました。

これらの例は、設定ミスがデータ漏洩からシステム全体の侵害まであらゆる事態につながり得ることを示しており、適切な設定管理の必要性を強調しています。

リソース消費の無制限: レート制限だけでなくクォータも

CI/CDでパフォーマンスとコストの予算を実施する
リクエスト数/分を超えて、トークン・アプリごとのダウンストリームコール、ペイロードサイズ、CPU時間、キュー使用量の予算を設定します。ルートが短いk6スモークランでp95レイテンシまたはエラー予算を超えた場合はビルドを失敗させ、本番環境ではゲートウェイスロットルを適用します。
ゲートウェイポリシー（Kongの例）：

これにより、「安価な」悪用（多数の小さなリクエスト）と「高価な」悪用（少数の重いリクエスト）の両方を防ぎます。

5. サーバーサイドリクエストフォージェリ（SSRF）

サーバーサイドリクエストフォージェリ（SSRF）は、APIがリモートリソースをフェッチするためにユーザーが提供した未検証のURLを受け入れ、サーバーを悪意のあるリクエストのツールにしてしまうときに発生します。

SSRFは多くの場合、APIが画像や文書などの外部コンテンツを取得するためにURLを入力として受け入れるときに発生します。適切な検証なしに、攻撃者はこれらのリクエストを内部システム、クラウドメタデータサービス、または他の機密エンドポイントにリダイレクトできます。

2020年には、Shopify ExchangeのSSRF攻撃の欠陥により、特定のコンテナへのルートアクセスが可能になりました。同様に、Capital Oneの侵害にはSSRF脆弱性が含まれており、1億人以上のユーザーに影響を与える資格情報が公開されました。

SSRFはファイアウォールなどのネットワーク防御をバイパスし、アクセス不能のままであるべき内部システムへのアクセスを許可できるため、特に危険です。これにより、内部インフラを侵害する可能性が強調されています。

6. 機能レベル認可の不備

機能レベル認可の不備は、APIが異なるユーザーロールと権限の間で適切なチェックを実施できない場合に発生します。この脆弱性については、機能レベル認可の不備に関する専用記事で詳しく解説しています。この問題は多くの場合、複雑なアクセス構造から生じます。たとえば、標準ユーザーと絡み合ったレイヤー化された管理グループのように、誰が何をできるかが不明確な状況です。このような状況では、開発者が管理アクションや機密機能の制限を忘れ、意図せず正しいエンドポイントを知っている誰でもアクセス可能にしてしまう可能性があります。

Shopifyのような小売プラットフォームの背後にあるAPIを考えてみてください。APIが通常ユーザーとストア管理者を適切に区別できない場合、巧みな攻撃者は管理者専用のエンドポイントを発見して、販売データの閲覧、価格変更、在庫管理など、適切な権限なしにアクションを実行できる可能性があります。

実質的に、これらの見落としにより悪意のある攻撃者はシステム内で「レベルアップ」し、隔離されているべき機能を乗っ取ったりデータを閲覧したりすることができます。これにより、API開発者が厳格なサーバーサイドチェックを実施し、各リクエストがそのリクエストをするユーザーに本当に許可されていることを確認することが重要になります。このステップをスキップすることは、マンションビル全体のスペアキーを配布しながら誰もペントハウスのドアを試みないことを望むようなものです。

機密ビジネスフローへの無制限アクセス: 具体的な防御策

高価値フロー（チケット、支払い、ギフトカード）の保護
悪用はしばしば正当なエンドポイント（例: カート -> チェックアウト）に隠れています。ステップトークン（フロー状態上のHMAC）、ユーザー・デバイス・ASNごとのベロシティルール、リプレイをブロックする冪等性キーを追加します。一括操作にはクォータとレビューのある非同期ジョブを公開し、スクリプト化可能な同期エンドポイントは使用しません。

7. サードパーティAPIの安全でない使用のリスク

サードパーティAPIの安全でない使用は、開発者がデフォルトで外部APIを信頼し、厳格な検証とセキュリティチェックをスキップするときに発生します。この誤った信頼は攻撃者への扉を開き、攻撃者はしばしば厳重に守られていない統合をバックドアとして標的にします。

ここには二重の危険があります。まず、悪意のある攻撃者が、決済プロセッサ、マッピングサービス、TwilioやSlackなどのコミュニケーションツールなど、セキュリティが弱い外部APIからの応答を操作し、アプリケーションが汚染されたデータや不正なリクエストを受け入れるように欺くことができます。次に、人気のあるサードパーティサービスが侵害された場合、それと統合されているアプリケーションもそのリスクを意図せず継承する可能性があります。

侵害された気象データプロバイダーが悪意のあるスクリプトを提供したり、機密の設定詳細を公開したりする場合を考えてみてください。攻撃者はこの間接的なルートを活用して攻撃を開始し、データを窃取し、コアAPIを直接侵害することなく特権機能へのアクセスを得ることができます。

最終的に、適切な検証なしに外部APIに過度に依存することは、見知らぬ人を家に招き入れてWi-Fiパスワードを盗まないことを期待するようなものです。防御的なコーディング、警戒心のある監視、明確な境界が悪用を防ぎ、APIを複雑なエコシステムの最弱リンクにしないために不可欠です。

SSRF: デフォルトでプライベートアドレス範囲をブロックする

APIがURLをフェッチする際はデフォルトで拒否する
サーバーサイドフェッチの前に、プライベート・リンクローカル・メタデータ範囲を拒否し、ホスト名の許可リストを必要とします。クラウド環境ではIMDSv2とメタデータホップ制限を実施します。

安全でないものは400で拒否し、意図をログに記録してアラートを発します。

1. セキュリティの設定ミスへの対処

強力な認証と入力検証があっても、設定ミスのあるシステムはAPIを脆弱にさらす可能性があります。セキュリティの設定ミスは、デフォルト設定、不要なサービス、または安全でない設定が適用されたままになる場合に発生します。一般的な問題には以下が含まれます。

• 有効なままのデフォルト管理者アカウントまたは認証情報。

• 無制限のCORSまたはオープンエンドポイント。

• 内部ロジックやスタックトレースを明かす詳細なエラーメッセージ。

• 不足しているHTTPセキュリティヘッダー（HSTS、CSP、X-Content-Type-Optionsなど）。

これを修正するためのベストプラクティス：

• すべてのサーバー、ゲートウェイ、API設定を強化します。

• 未使用の機能とエンドポイントを無効にします。

• 自動化された設定チェックを実装します。

• 設定ミスによる誤動作のログを定期的に確認します。

1. 初期リスク評価とAPIインベントリ

APIを保護する最初のステップは、何を保護しているかを理解することです。APIが今日のトラフィックの多くを占めているにもかかわらず、多くの組織はどのエンドポイントが機密データを公開しているかを特定するのに苦労しています。この可視性の欠如は大きなセキュリティリスクをもたらします。

まず、自動化ツールを使用して、正式な監視なしにデプロイされた可能性のある文書化されていないAPIを見つけます。すべてのAPIエンドポイントをカタログ化し、その目的、処理するデータ、現在のセキュリティステータスを記録します。このインベントリがセキュリティ取り組みの基盤となります。

適切で最新のドキュメントも同様に重要です。APIは従来のWebアプリよりもはるかに多くのエンドポイントを公開する傾向があるため、インベントリのギャップや古いドキュメントがあるとリスクが見えなくなる可能性があります。エンドポイントだけでなく、デプロイされたホストとAPIバージョンの生きたインベントリを維持します。非推奨バージョン、公開されたデバッグエンドポイント、シャドウAPIを追跡することで、攻撃者が忘れられた、またはセキュリティが弱いインターフェースを悪用するのを防ぎます。完全で正確なインベントリとドキュメントが揃うことで、脆弱性の特定、古いエンドポイントの廃止、そして時間の経過とともにAPIを安全に進化させるための準備が整います。

APIを文書化・評価する際には、チケット購入、コメント投稿、金融取引などのビジネスフロー全体を公開するエンドポイントに特に注意を払います。これらのフローに対する適切なコントロールが欠如しているAPIは、実装バグではなくビジネスロジックを悪用する自動化攻撃など、悪用に対して特に脆弱になる可能性があります。例えば、攻撃者がチケットを素早く購入したり、自動化されたコメントでアプリケーションを溢れさせたりできる場合、技術的に認証や検証が健全であっても、ビジネスへの影響は大きくなる可能性があります。

APIの状況を評価する際には、コーディングバグによる脆弱性がなくても大規模に悪用される可能性のあるビジネスフローに特に注意を払います。例えば、ユーザーがチケットを購入したり、レビューを投稿したり、ビジネスに影響を与えるアクションを実行できるAPIは、自動化によってどのように悪用される可能性があるかを評価する必要があります。レート制限、行動分析、CAPTCHAなどの適切なコントロールなしにこれらのフローを公開すると、詐欺やサービス妨害などの重大なビジネスリスクへの扉を開く可能性があります。すべての脅威が技術的な脆弱性から生じるわけではありません。時には補完的なコントロールの欠如がビジネスをリスクにさらすことがあります。

インベントリが重要な理由：
APIは従来のWebアプリケーションよりも多くのエンドポイントを公開する傾向があり、適切で最新のドキュメントが絶対に不可欠です。すべてのホスト、デプロイされたバージョン、環境を含む包括的で最新のインベントリがなければ、非推奨エンドポイントや忘れられたデバッグAPIが見落とされる可能性が高くなります。これらの見落とされた、または古いエンドポイントは、監視が少なく最新のセキュリティコントロールが欠如していることが多いため、攻撃者の格好のターゲットになります。

徹底的に：

• すべてのホストとデプロイされたAPIバージョンを文書化します。

• APIが進化、バージョン管理、または廃止されるにつれてインベントリを定期的に更新します。

• ステージング、開発、デバッグポイントを含むすべてのエンドポイントが把握されていることを確認します。

堅牢で適切に維持されたAPIインベントリは、古い、または公開されたエンドポイントからのリスクを軽減するだけでなく、効果的なリスク評価と脆弱性管理の基盤を設定します。

次に、現在のセキュリティ対策をOWASP API トップ10と比較してギャップ分析を実施します。この分析では、不足している認証、過剰なデータ公開、不十分なログなどの問題を特定します。特定されたら、関連するデータの機密性と潜在的なビジネスへの影響に基づいて脆弱性を優先し、CVSSカリキュレーターを使用して一貫した深刻度スコアを割り当てます。

APIセキュリティへの投資を正当化するために、リスクを定量化します。規制上のペナルティ、顧客の信頼の喪失、運営のダウンタイムなどの侵害の潜在的なコストと、より強力なセキュリティ対策の実施コストを比較します。このアプローチは、ステークホルダーに対する投資収益率を明確にするのに役立ちます。

不適切なインベントリ管理: シャドウAPIの阻止

発見と非推奨化
権威あるインベントリ（OpenAPI・GraphQLスキーマ、オーナー、認証、PIIフラグ）を維持し、トラフィックとスペックを比較して追跡されていないエンドポイントと古いバージョンを表面化します。スキーマの差分でマージをゲートし、v-1ルートの廃止計画を必須にします。

• 本番環境で非所有のサブドメインとテストホストへのコールをブロックします。

• PIIを受け取っている認証なしエンドポイントに対してアラートを発します。

• 攻撃者より先に新しいルートをキャッチするために毎晩ディスカバリーを実行します。

1. APIの安全な使用の確保

多くの現代のアプリはサードパーティAPIに依存しています。盲目的に使用すると、自分のAPIが安全であっても脆弱性をもたらす可能性があります。一般的なリスクには以下が含まれます。

• 外部サービスからの不正なまたは悪意のある応答。

• サードパーティAPIを統合する際の機密データの公開。

• インジェクションまたはロジック攻撃を引き起こす未検証の外部ペイロード。

これらのリスクを軽減するためのベストプラクティス：

• 使用前に外部APIからのすべてのデータを検証・サニタイズします。

• スキーマ検証を使用して期待される構造を実施します。

• 外部コールにレート制限、タイムアウト、リトライを適用します。

• 異常または疑わしい動作を検出するためにすべてのインタラクションをログに記録します。

安全でないAPIの使用: サプライヤーを信頼できないものとして扱う

信頼の境界はゲートウェイで終わらない
ユーザー入力と同様にサードパーティの応答を検証・サニタイズします。パートナーからの受信データにmTLS、厳格なタイムアウト・リトライ、スキーマチェックを実施し、キーをローテーションし、パートナートラフィックを別のegressとクォータで隔離します。

• スキーマのドリフトを監視し、安全でない変更は失敗させます。

• カスケードするパートナー障害を避けるためにキャッシュ・キューを使用します。

• 侵害されたベンダー用のキルスイッチを用意します。

2025年のAPIセキュリティの主要リスク

APIへの主要な脅威を理解することは、安全で現代的なアプリケーションを構築するために重要です。今年、開発者とセキュリティチームが注意すべき最も重要なAPIセキュリティリスクの概要を以下に示します。

• オブジェクトレベル認可の不備：攻撃者は、APIがユーザー提供のIDで識別されるリソースへのアクセスを処理する方法の欠陥を悪用します。厳格なパーミッションチェックなしに、ユーザーはオブジェクト識別子を微調整するだけで不正アクセスを得られる可能性があります。

• 認証の不備：弱い、または不適切に実装された認証により、攻撃者がトークンやセッションデータを乗っ取り、アカウントの乗っ取りとプライバシー侵害につながります。OAuth 2.0とMFAを使用するなど、認証の堅牢性を確保することは必須です。

• オブジェクトプロパティレベル認可の不備：APIは個々のプロパティレベルでのアクセスを適切に制限できない場合があり、機密データの漏洩やユーザーが変更してはならないフィールドの変更を許可してしまいます。オブジェクトとプロパティの両方のレイヤーで強力な認可検証が不可欠です。

• リソース消費の無制限：APIはシステムリソース（帯域幅、CPU、メッセージングサービス）へのゲートウェイです。フィルタリングされていない多数のリクエスト（悪意のある、またはそうでない）は、コストを増加させ、パフォーマンスに影響を与え、またはサービス拒否状態を引き起こす可能性があります。

• 機能レベル認可の不備：すべてのAPI機能が同じというわけではありません。管理操作と通常の操作の間に明確な分離がない場合、攻撃者は権限を昇格させ、管理者向けの機能にアクセスし、システムを重大な悪用にさらす可能性があります。

• 機密ビジネスフローへの無制限アクセス：一部のビジネスプロセス（チケット購入や大量のコメントなど）は、自動化に対するセーフガードなしにAPIを通じて公開されています。これは詐欺、スキャルピング、スパムのために悪用される可能性があり、ユーザーとビジネスの両方に損害を与えます。

• サーバーサイドリクエストフォージェリ（SSRF）：APIがユーザー提供のURLを検証せずにリモートリソースをフェッチする場合、攻撃者はサーバーをプロキシとして機能させ、通常は一般公開から遮蔽されている内部システムやクラウドメタデータエンドポイントを標的にすることができます。

• セキュリティの設定ミス：複雑な設定はしばしば見落とされるリスクにつながります。デプロイメントのギャップや弱いデフォルトが脆弱性を開くため、定期的な監査とベストプラクティスへの準拠が重要です。

• 不適切なインベントリ管理：公開されたエンドポイント、古いAPIバージョン、テスト・デバッグインターフェースを追跡できなくなると、シャドウAPIと不必要な攻撃対象領域が生まれます。詳細で最新のドキュメントとインベントリを維持することで、これらの扉を閉じることができます。

• サードパーティAPIの安全でない使用：適切な精査なしに外部APIからのデータを信頼することでリスクが生じます。サプライチェーンの弱点、弱いセキュリティ基準、間接的な侵害がこれらの統合を通じて入り込む可能性があります。

参考：APIセキュリティチェックリスト、API攻撃、一般的なAPI脆弱性

これらのコアリスクを認識することで、防御の優先順位を付け、現代の脅威に対して強固なAPIを構築できます。

API脆弱性の修正方法

API脆弱性の修正には、OWASP トップ10の脅威に対して保護するためにさまざまなセキュリティ対策をレイヤーすることが含まれます。各レイヤーは特定のリスクに対処し、連携してより強力な防御を構築します。

強力な認証と認可の設定

認証はユーザーアイデンティティを確認し、認可はどのアクションが許可されるかを決定します。APIを保護するために：

• パスワードなし認証のためにOAuth 2.0とJWTを使用します。開発中にテスト用APIキーを生成するには、APIキージェネレーターをお試しください。

• 機密性の高いアプリケーションに多要素認証（MFA）を追加します。

• 最小権限の原則に基づいたロールベースアクセスコントロール（RBAC）を実装し、ユーザーに必要な権限のみを付与します。

• 以下によって安全なトークン管理を確保します。

  • すべてのAPIコールにHTTPSを使用します。

  • 定期的にトークンをローテーションします。

  • 有効期限ポリシーを設定します。

  • トークンを安全に保存します。

これらのステップは、OWASP トップ10に記載されている認証の不備の脆弱性に直接対処します。まだ始めていない場合は、APIセキュリティ101ガイドで認証の基礎とレイヤー化した防御戦略を確認してください。

認証が整ったら、次のステップは潜在的な攻撃ベクターをブロックするためにすべての入力データを検証・サニタイズすることです。

入力データの検証とサニタイズ

入力検証とサニタイズは、インジェクション攻撃とデータ操作に対して防御するために不可欠です。ほとんどの脆弱性は不適切な入力処理から生じるため、以下の実践に焦点を当ててください。

• 主要な防御としてサーバーサイド検証を使用します。

• パラメータ化されたクエリとプリペアードステートメントを使用してSQLインジェクションを防ぎます。

• 許容可能な文字、形式、値のみを許可するホワイトリスト検証を通じて厳格な入力ルールを定義します。

• 応答に含める前に特殊文字をエンコードすることで、クロスサイトスクリプティング（XSS）攻撃をブロックするために出力をサニタイズします。

さまざまな入力タイプを効果的に処理する方法を以下に示します。

エラーメッセージで機密システムの詳細を公開することを避けてください。代わりに、内部設定やロジックを明かさずにユーザーに情報を伝えるジェネリックな応答を使用します。

さらに、正規表現を使用して入力から不必要な文字を削除します。例えば、英数字または特定の記号のみを許可することで、有害なコンテンツがシステムに入るリスクを軽減します。

入力検証が整ったら、次は悪用を防ぐためにトラフィックを管理することに焦点を当てます。

レート制限とスロットリングの適用

レート制限とスロットリングは、正当なユーザーの信頼できるパフォーマンスを維持しながら、APIの悪用から保護するのに役立ちます。APIのニーズに応じて、さまざまなアルゴリズムを使用できます。

• 固定ウィンドウ: シンプルです。

• スライディングウィンドウ: よりスムーズなコントロールを提供します。

• トークンバケット: トラフィックのバーストを効果的に処理します。

• リーキーバケット: 一定のリクエストフローを確保します。

APIゲートウェイにより、これらのルールを実施しトラフィックを集中管理しやすくなります。

エンドポイントのタイプと使用パターンに基づいて段階的なレート制限を設定します。例を以下に示します。

リクエストパターン、エラー率、サーバー負荷などのメトリクスを追跡して、制限を動的に調整します。ピーク時には、動的レート制限により可用性を維持しながらサーバー負荷を最大40%削減できます。

APIレスポンスヘッダーでレート制限を明確に伝えます。X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Resetなどの情報を含めることで、クライアントが使用状況を監視しリクエストを計画できます。

ダウンストリームサービスのカスケード障害を防ぐためにサーキットブレーカーを使用します。サービスが過負荷になった場合、サーキットブレーカーはリクエストを一時的に停止し、システムが回復する時間を与えます。

悪用を効果的に管理するために適切な時間ウィンドウとブロック期間を設定します。例えば：

• リクエスト追跡には15～60分のウィンドウを使用します。

• 一時的な制限には5～30分のブロックを適用します。

• 使用クォータには24時間のリセット期間を実装します。
  
  

「APIレート制限は、要するに、APIの運用者または所有者が設定したルール・ポリシーに基づいてAPIにアクセスする人（およびボット）へのアクセスを制限することです。」- DataDome

QodexのAI搭載APIセキュリティツールの活用

手動セキュリティテストは時間のかかるプロセスであり、重大な脆弱性を見落とすことが多いです。Qodexは、AIを活用してAPIセキュリティテストに積極的なアプローチを取り、OWASP トップ10基準に沿った問題の自動検出とテストシナリオの作成を行います。この自動化された戦略は、脆弱性が発生した際に対処することで継続的な保護を確保します。

自動化されたAPI脆弱性検出

QodexはAIを使用してAPIエンドポイントを分析し、OWASP トップ10に基づいたセキュリティ重視のテストシナリオを生成します。オブジェクトレベル認可の不備（BOLA）から不十分なログと監視まで、すべての主要な脆弱性をカバーします。

必要なのはAPIコレクション（QodexはPostman、Swagger、OpenAPIファイルをインポートします。もし評価中であればPostmanの代替手段のまとめもご覧ください）をアップロードするだけで、QodexのAIがターゲットを絞ったテストを作成します。例えば、認証の不備に対処するために弱い、または欠落している認証コントロールを特定します。過剰なデータ公開については、APIレスポンス内の機密データや過剰に公開されたフィールドを見つけ出します。また、APIが予期しないフィールドを処理するかどうかを検証することでマスアサインメントの脆弱性もチェックします。

「Qodex.aiは私たちの製品を理解し、人間の介入なしにすべてのシナリオ（ユニット、統合、セキュリティ監査）を書きます。リリースログも提供してくれます。」- Vishal C、共同創業者 兼 CTO、スモールビジネス [4]

プラットフォームはAPIが変更された際に自動的に適応し、手動調整なしにセキュリティテストを最新の状態に保ちます。OWASP トップ10テストを開始するには、AIエージェントを使用して「私のAPIでOWASP トップ10を実行して」または「一般的なAPIセキュリティの問題をテストして」などのコマンドを入力するだけです。AIがエンドポイントを評価し、カスタマイズされたセキュリティテストシナリオを生成します。

OWASP トップ10シナリオのノーコードAPIテスト

従来のセキュリティテストには高度なコーディングスキルが必要ですが、Qodexはノーコードテスト作成を可能にしてこのハードルを取り除きます。開発者とプロダクトマネージャーは、複雑なフレームワークやプログラミングの専門知識を必要とせずに、プレーンな英語でセキュリティテストケースを作成できます。

「テストケースを書くためのシンプルなインターフェースを提供しています。プレーンな英語で入力するだけで、正確なテストケースに変換されます。これにより、開発者やプロダクトマネージャーがコードと要件をテストしやすくなります。」- Debbie M、マーケティングマネージャー、スモールビジネス [4]

このアプローチにより、OWASP トップ10テストスイートの作成は問題を説明するほど簡単になります。例えば、「ユーザーが他のユーザーのデータにアクセスできるかチェックして」と入力するとオブジェクトレベル認可の不備のテストが生成され、「ログインフォームでSQLインジェクションをテストして」と入力するとインジェクション攻撃のシナリオが作成されます。

このアクセシビリティにより、チーム全体が強化されます。専任のセキュリティ専門家に依存せずに、開発者とマネージャーが潜在的なセキュリティリスクを特定できます。

「最良の部分はそのテストシナリオであり、開発者やPMが自分たちだけで作成できます。使用が非常に簡単でCI/CDパイプラインとの統合も容易です。」- Kulsoom S、エンジニアリングマネージャー、スモールビジネス

継続的なセキュリティとCI/CD統合

Qodexはテスト作成を簡素化するだけでなく、現代の開発ワークフローにシームレスに統合することで継続的なセキュリティを確保します。

セキュリティテストは一度きりのタスクではなく、継続的なプロセスです。QodexはCI/CDパイプラインに容易に統合し、開発ライフサイクル全体でAPIセキュリティの継続的な監視を可能にします。GitHub統合をサポートし、あらゆる段階でスキャンとポリシーの実施を自動化します。

「すべての手動テストをQodexで自動化テストに移行しました。CI/CDツールと簡単に統合でき、重大なバグの検出に役立ちます。」- Mohanlal R、リードソフトウェアエンジニア、スモールビジネス

各コミットが自動的にOWASP トップ10テストをトリガーします。脆弱性が見つかった場合、Qodexは実行可能な修正手順を含む詳細なレポートを提供し、問題が本番環境に到達する前に対処されることを確保します。これにより、すべてのリリースで一貫したセキュリティ標準が維持されます。

堅牢なセキュリティを維持するために、新しいAPIコレクションでOWASP トップ10テストを実行し、重要なユーザージャーニー（認証、支払い、PII処理など）にこれらのテストを含め、テストプランで週次の完全テストランをスケジュールします。ダッシュボードによりカバレッジとトレンドを追跡でき、レポートは時間の経過に伴うセキュリティポスチャの監視に役立ちます。

OWASPに準拠したAPIセキュリティプログラムの構築

APIの長期的な保護を確保するために、OWASP標準に基づく構造化されたセキュリティプログラムを確立することが不可欠です。84%の組織が昨年APIセキュリティインシデントを経験していることを考えると、これは単なる予防策ではなく、必要不可欠なことです。

「APIは今日のデジタル世界のバックボーンであり、フィンテックアプリからスマートホームガジェットまですべてをつないでいます。APIが実質的にすべてのデジタル体験を支えていることを考えると、APIセキュリティフレームワークの設定方法を知ることは単に良いことというだけでなく、ビジネスの死活問題です。」
Adrian Machado、スタッフエンジニア

以下では、強力なAPIセキュリティプログラムを構築・維持するための実行可能なステップを探ります。

開発ワークフローへのセキュリティの組み込み

リスクを評価してAPIを文書化した後は、開発プロセスにセキュリティを組み込む時です。セキュリティは最初から開発ワークフローのコア部分であるべきで、後付けであってはなりません。例えば、すべてのプルリクエストが自動化されたセキュリティスキャンをトリガーして脆弱性を早期にキャッチすることができます。

採用すべきベストプラクティスを以下に示します。

• OAuth 2.0の使用：セキュリティとユーザーの利便性のバランスを取るために、リフレッシュトークンを使用した短命のアクセストークン（15～30分）を採用します。

• レート制限の設定：各エンドポイントの動作に合わせたレート制限ルールを作成します。例えば、認証エンドポイントは他のエンドポイントよりも厳格な制限が必要な場合があります。

• データ保持ポリシーの定義：データストレージを制限して露出を減らします。これはユーザーデータ、ログ、キャッシュされた応答、一時ファイルに適用されます。

• セキュリティテストの自動化：自動スキャンをCI/CDパイプラインに統合します。新しいコードが脆弱性をもたらさないことを確保するために、定期的にOWASP トップ10に対してテストします。

継続的な改善とインシデントレスポンス

強力なAPIセキュリティポスチャを維持するには、継続的な監視とインシデントへの準備が必要です。予防策だけでは十分でなく、脅威をリアルタイムで検出・対応する必要もあります。

• トラフィックの監視：予期しないデータアクセスや高いリクエスト量など、異常なアクティビティを特定するためにリアルタイム監視を使用します。

• 包括的なログの実装：認証イベント、データアクセスパターン、エラー、セキュリティ違反をキャプチャする監査証跡を作成します。これらのログは調査とコンプライアンスに非常に価値があります。

• インシデントレスポンス計画の確立：データ侵害やサービス拒否攻撃などの一般的なAPIセキュリティインシデントを処理するためのステップバイステップの手順を作成します。役割を割り当て、コミュニケーションチャネルを定義し、迅速で協調した対応を確保するために回復手順を概説します。

防御を鋭く保つために、定期的なセキュリティ監査とペネトレーションテストを実施します。倫理的なハッカーや自動化ツールは実際の攻撃をシミュレートしてシステムの弱点を明らかにすることができます。

最後に、チームへの継続的な教育に投資します。セキュアなコーディング実践、入力検証、その他のAPIセキュリティの基本について、使用している技術スタックに固有の例を使用してトレーニングを提供します。新たな脅威と業界の進展に対応するためにこれらのセッションを定期的に更新します。

「私たちは確かにこの新興APIセキュリティ空間の初期段階にいますが、今後のAPIセキュリティについて考えると、それは現代のアプリケーションの根本的な基盤になるでしょう。」
Tyler Reynolds、Kongのシニアソリューションアーキテクト兼Traceable.aiのチャネル & GTMディレクター

GraphQLとgRPC: リスクのマッピング

GraphQLはフィールドレベルでBOPLAリスクを集中させます。機密フィールドには永続クエリ、深さ・複雑さの制限、スキーマベースの許可リストを実施します。gRPCでは、.protoの変更をコントラクトとして扱います。後方互換性のあるフィールド進化を必須にし、デッドラインを実施し、リソース枯渇を避けるためにリトライ・バックオフを検証します。これらのガードレールはAPI2、API3、API4、API5のリスクに直接対応します。

パイプラインでのOWASPチェックの自動化

すべてのPRでOpenAPIリント、ネガティブ認可テスト、DASTスモークを実行してシフトレフトを実現し、深刻度の高い調査結果があればマージを失敗させます。例のワークフロー: Spectral（スペックリント）-> Newman（ネガティブテスト）-> ZAPベースライン（ステージングでのDAST）。

これは競合他社の「シフトレフト」ガイダンスを反映していますが、読者にとってコピーレディな形式です。

関連： APIセキュリティベンダーのトップ: 機能とサービスの比較

結論: APIセキュリティの主要ポイント

現代のデジタルシステムにおけるAPIセキュリティの確保

APIセキュリティは、ますます巧みになる脅威からデジタルシステムを守るために不可欠です。API攻撃が前年比300%以上急増し、オブジェクトレベル認可の不備が報告されたAPIセキュリティ侵害の大半に責任があることを考えると、OWASP APIセキュリティ トップ10への対処は最優先事項であるべきです。

実際の侵害は、オブジェクトIDの操作や過剰なデータ公開などの脆弱性を悪用することが多いです。これらのリスクに対抗するために、堅牢な認証と認可の対策が重要です。実践的なチェックリストとして、2026年向けAPIセキュリティの15のベストプラクティスをご覧ください。これには多要素認証、安全なセッション管理、厳格なアクセスコントロールが含まれます。強力な認証と認可に加えて、APIがリクエストごとに消費するリソース（ネットワーク帯域幅、CPU、メモリ、ストレージ、さらにはメール、SMS、電話認証などの付随サービスまで）を考慮することが重要です。未チェックのままでは、リソース消費の無制限により、チームを驚かせる予期しないサービス拒否攻撃や運営コストの急増にAPIをさらす可能性があります。

さらに、レート制限、リソースクォータ、APIスロットリングなどの戦略は、サービス拒否攻撃を軽減し、攻撃を受けても正当なユーザーがAPIにアクセスできるようにします。

これらの実践的なコントロールにより、単一のクライアント（または悪意のある攻撃者）がインフラを圧倒するのを防ぎ、膨大な使用料から収益を守ることができます。APIリクエストを満たすには貴重なリソース（ネットワーク帯域幅、CPU、メモリ、ストレージ）が消費されます。一部のサービスプロバイダーは、API統合を通じてメール送信、SMS、または生体認証などのリソース集約型機能を提供しており、リクエストごとにコストが発生することも多いです。未チェックのままでは、攻撃者がこれらのエンドポイントを悪用し、運営コストを増加させたり、インフラを圧倒したりする可能性があります。リソース割り当てを積極的にコントロールし、使用制限を実施することで、システムのパフォーマンスと収益の両方を守ることができます。これらの積極的な手順が自動化されたセキュリティソリューションの統合への基盤となります。

現代のAPI環境の複雑さを考えると、手動テストだけでは不十分です。DASTやAI搭載プラットフォームなどの自動化ツールは、脆弱性をリアルタイムで特定・対処するために重要な役割を果たします。Gartnerは2025年までにデータ窃取インシデントの半数以上が安全でないAPIから生じると予測しています。Qodexのようなツールは、脆弱性検出の自動化、OWASPシナリオのノーコードテストの実現、CI/CDパイプラインへのシームレスな統合によってこのプロセスを合理化します。これにより、チームは開発の早い段階でセキュリティ問題をキャッチ・解決し、コンプライアンスを維持し、手動テストに関連するリスクを最小化できます。

APIセキュリティは一度きりの取り組みではなく、継続的な警戒が必要です。定期的な監査、更新されたドキュメント、積極的な脅威検出が不可欠です。入力検証や最小権限の原則などの実践は、機密データが認可されたユーザーのみアクセスできるようにすることでリスクを最小化するのに役立ちます。セキュリティの設定ミスや不適切なインベントリ管理などの一般的な問題は、ドキュメントを最新に保ち、確立されたベストプラクティスに従い、設定チェックを自動化することで対処できます。

OWASP APIセキュリティ トップ10は新たな脅威と攻撃手法に対応するために定期的に進化しています。これらの更新について最新情報を把握することは、強力なセキュリティポスチャを維持するために重要です。このガイドで説明した戦略を適用し、現代のセキュリティツールを活用することで、組織のデータと評判を危険にさらす可能性のあるAPI脆弱性に対して強固な防御を構築できます。

よくある質問

OWASP トップ10の脆弱性とは何ですか？

OWASP トップ10の脆弱性は、Open Web Application Security Projectによって特定された最も重大なセキュリティリスクを示しています。これらのカテゴリーは、ハッカーが悪用することの多いインジェクション攻撃、認証の不備、安全でないオブジェクト参照などの一般的な欠陥を強調しています。OWASP トップ10は、開発者、テスター、セキュリティエンジニアが防御の取り組みをどこに集中させるか、APIセキュリティテストをどのように優先するかを理解するための標準的な啓発文書として機能します。

OWASP標準とは何ですか？

OWASP標準は、ソフトウェアとAPIのセキュリティを強化するために作成された世界的に認められたベストプラクティスとフレームワークです。セキュアなコーディング、脅威モデリング、リスク管理のための構造化されたガイドラインを提供します。OWASP標準に従うことで、組織は現代のセキュリティ要件への準拠を確保し、侵害につながる前に脆弱性を特定・軽減するための積極的なアプローチを確立します。

OWASPガイドラインとは何ですか？

OWASPガイドラインは、安全なWebおよびAPIアプリケーションを設計、構築、維持するための開発者とセキュリティチームへの詳細な推奨事項です。これらのガイドラインは、入力検証からセッション管理、アクセスコントロールまでを網羅しています。OWASPガイドラインに従うことで、チームの開発プロセスを実証済みのセキュリティ対策に合わせ、OWASP トップ10の脆弱性への露出を減らし、アプリケーションの全体的な回復力を向上させることができます。

OWASPの原則とは何ですか？

OWASPの原則は、セキュリティをデザインに組み込んでアプリケーションを構築することを促進する基礎的なセキュリティの哲学です。最小権限、多層防御、安全なデフォルトなどの原則を強調しています。これらの原則が開発のすべてのフェーズに組み込まれると、人的エラーの削減、設定ミスの防止、チームと技術全体にわたる一貫したセキュリティ文化の確立に役立ちます。

OWASPの脆弱性とは何ですか？

OWASPの脆弱性とは、実世界のデータと研究を通じてOWASPコミュニティによって特定された一般的なセキュリティ上の弱点を指します。これには、データの整合性とユーザーのプライバシーに深刻なリスクをもたらす、壊れたアクセスコントロール、暗号化の失敗、インジェクションの欠陥などの問題が含まれます。OWASPの脆弱性を理解することで、開発者はテストを優先し、コードの品質を向上させ、より良いリスク軽減戦略を採用できます。

OWASPツールとは何ですか？

OWASPツールは、開発者とセキュリティの専門家が脆弱性を効率的に検出、分析、修正するために設計されたオープンソースのユーティリティとフレームワークです。OWASP ZAP、Dependency-Check、WebGoatなどの人気ツールは、ペネトレーションテスト、依存関係スキャン、セキュアなコーディング教育を支援します。これらのツールを活用することで、継続的なAPIセキュリティテストが可能になり、アプリケーションをOWASP トップ10のベストプラクティスに沿わせることができます。