OWASP Top 10 API セキュリティリスク

Open Worldwide Application Security Project（OWASP）は、ソフトウェアセキュリティの向上を目的とした非営利団体です。OWASPは、組織が Web アプリケーションのセキュリティを確保できるように、ツール、手法、ドキュメントなどのオープンリソースを無料で提供しています。OWASPの最もよく知られている貢献の1つは、APIセキュリティの最も重大なリスクを浮き彫りにしたトップ10 APIセキュリティリスクです。2023年の更新では、アプリケーション・プログラミング・インターフェース（API）とWebアプリケーションのセキュリティ確保の重要性と固有の課題が増大していることが反映されています。

API は、各種ソフトウェアアプリケーションが互いに通信するための一連のルールとプロトコルです。APIの重要な機能は、テクノロジー間での効率的なデータ交換を促進することです。最新のアプリケーションアーキテクチャの基本テクノロジーであるAPIを使用すると、データを複製したり、サービスをゼロから構築したりすることなく、1つのアプリケーションが他のアプリケーションやサービスから情報を要求し、機能を活用できます。APIはデジタル世界の中心であり、アプリケーション、システム、データを接続します。

2024年のAPIセキュリティの影響に関する調査に参加した1,200人以上のITおよびセキュリティ専門家によると、84%の組織が過去12か月間にAPIセキュリティインシデントを経験しています。最新のアプリケーションアーキテクチャにおけるAPIの急速な増加に伴い、サイバー犯罪者はいくつかの理由でAPIを攻撃ベクトルとして利用するようになりました。

• 普及：APIは最新のソフトウェア開発のいたるところに存在し、Webアプリケーションやモバイルアプリケーション、IoTデバイス、さまざまなプラットフォーム間の統合を強化しています。このように広く採用されていることで、攻撃者にとっての新たな潜在的な標的がたくさん生まれ、組織のアタックサーフェスが拡大します。
• 機微な情報へのアクセス：API は、機微な情報（個人情報、財務情報、機密ビジネスデータなど）を処理します。攻撃者はAPIを悪用することで、アイデンティティの窃盗、金融詐欺、企業スパイに使用できる貴重な機密情報にアクセスできます。
• バックエンドシステムへの直接アクセス：APIはバックエンドシステムやデータベースに直接アクセスでき、多くの場合、従来のユーザーインターフェースをバイパスします。この直接アクセスを悪用して、フロントエンドアプリケーションの通常のセキュリティチェックやバランスを行わずに、データの取得、変更、削除を行うことができます。
• 複雑さと設定ミス：APIは複雑で、多くのエンドポイントとバージョンがあり、それぞれに適切な設定とセキュリティが必要です。設定ミスやセキュリティのミスは一般的であり、API攻撃が成功する確率はかなり高くなります。
• 攻撃の自動化とスケーラビリティ：自動化されたツールやスクリプトを使用してAPIを標的にすることができるため、攻撃者は攻撃を容易にスケーリングできます。自動化された攻撃は、脆弱な認証メカニズムやその他のセキュリティ上の欠陥など、APIの脆弱性を迅速に悪用する可能性があります。
• サードパーティー統合：APIは多くの場合、サードパーティのサービスとの統合を促進します。これにより、追加のセキュリティリスクが生じる可能性があります。サードパーティのサービスが侵害されると、攻撃者がプライマリAPIを悪用するためのエントリーポイントとなります。
• 不十分なロギングと監視：多くの組織では、APIの適切なロギングと監視が行われていないため、疑わしいアクティビティをリアルタイムで検知して対応することが困難です。これにより、攻撃者は長期間検知されることなく、セキュリティの脆弱性を悪用できます。

OWASP Top 10 APIセキュリティリスクに含まれる具体的な脅威を理解するためには、APIに関連する重要な概念と用語を確認することが重要です。

• API エンドポイント：APIエンドポイントは、クライアントがAPIにアクセスできる特定のURLまたはパスです。各エンドポイントは、フォームの送信、データベースエントリの更新、ユーザー情報の取得など、さまざまな機能やリソースへのアクセスを提供します。
• コールとリクエスト：APIコールまたはリクエストとは、データを要求したり、アクションを実行したりするために、クライアントからAPIエンドポイントに送信されるメッセージです。APIコールまたはリクエストは、APIエンドポイントから応答を生成します。
• オブジェクト：オブジェクトは、ユーザー、製品、注文などの実際のエンティティを表すデータ構造です。オブジェクトには属性／プロパティおよびメソッド／関数を含めることができます。たとえば、ソーシャルメディアAPIでは、名前、プロフィール画像、Eメールなどの属性を持つユーザープロファイルや、友人リクエストの送信やプロファイルの更新などのメソッドを持つユーザープロファイルがオブジェクトになります。
• データバインディング：データバインディングは、APIリクエストからオブジェクトに入力データをマッピングするプロセスです。
• 認証：認証とは、API リクエストを行うユーザーまたはシステムのアイデンティティを検証するプロセスです。エンティティ認証またはユーザー認証の目的は、そのエンティティが、そのエンティティが主張する人または物であるかどうかを判断することです。
• 認可：認可は、認証されたユーザーまたはシステムに許可されるアクセス権限のレベルを決定します。

OWASP Top 10 APIセキュリティリスクは、APIにとって最も重大なセキュリティリスクを浮き彫りにしています。

• API1:2023 — オブジェクトレベルの認可の不備（BOLA）：この脅威は、APIがユーザー権限に基づいて特定のオブジェクトへのアクセスを適切に制限しない場合に発生します。つまり、権限のないユーザーが、許可されていないはずのデータにアクセスしたり変更したりして、機微な情報を公開したり、悪性のアクションを実行したりする可能性があります。
• API2:2023 — 認証の不備（BA）：認証の不備は、ユーザーのアイデンティティの検証に使用される方法に欠陥がある場合に発生します。これにより、攻撃者はユーザーアカウントを乗っ取り、不正アクセスを行い、正当なユーザーであるかのようにアクションを実行できます。
• API3:2023 — オブジェクト・プロパティ・レベルの認可の不備（BOPLA）：この問題は、APIがオブジェクト内のプロパティレベルで権限を適切にチェックしない場合に発生します。攻撃者が不正アクセスを行ったり、オブジェクト内の特定のデータフィールドを変更したりして、機微な情報を公開したり、悪性のアクションを実行したりする可能性があります。
• API4:2023 — 制限のないリソース消費：APIを機能させるには、ネットワーク帯域幅、CPU、メモリー、ストレージなどのリソースが必要です。APIにリソース消費の制限が十分にない場合、攻撃者は過剰なリクエストを行うことでAPIを過負荷状態にすることができ、サービス妨害や運用コストの増加につながります。
• API5:2023 — 機能レベル認可の不備（BFLA）：機能レベルの認可の不備は、APIがユーザーの役割に基づいて特定の機能やアクションへのアクセスを適切に制限しないことを意味します。これにより、ユーザーは管理機能へのアクセスなど、実行できないはずのアクションを実行できます。
• API6:2023 — 機密性の高いフローへの制限のないアクセス：APIは、アイテムの購入やコメントの投稿などのビジネスプロセスを公開する場合がありますが、これらの機能の悪用方法を適切に制御することはできません。攻撃者は、これらの機能の悪用を自動化して、ビジネスに損害を与える可能性があります。
• API7:2023 — サーバーサイドリクエストフォージェリ（SSRF）：SSRFは、ユーザーが提供したURLをAPIが適切に検証せずに、別のサーバーからリソースをフェッチする場合に発生します。攻撃者はこれを悪用して、APIサーバーが意図しない場所にリクエストを送信するようにし、ファイアウォールを迂回したり、内部システムにアクセスしたりする可能性があります。
• API8:2023 — セキュリティの設定ミス：セキュリティ設定のミスとは、APIの設定が誤っていたり不完全であったりすることであり、これによって攻撃に対して脆弱になります。これは、デフォルトの設定、パッチの欠如、セキュリティ制御の誤設定が原因で発生し、潜在的な悪用につながる可能性があります。
• API9:2023 — 不適切なインベントリ管理：このリスクは、APIが必要以上に多くのエンドポイントを公開している場合や、適切なドキュメントおよびバージョン管理が欠如している場合に発生します。攻撃者は、開発者が忘れているかもしれない、古い、非推奨の、またはセキュリティ保護されていないエンドポイントやAPIバージョンを悪用する可能性があります。
• API10:2023 — API の安全でない使用：開発者は、サードパーティAPIからのデータを信頼しすぎて、自身が使用しているのと同じセキュリティ標準をユーザー入力に適用しない可能性があります。攻撃者は、これらのサードパーティサービスの脆弱性を悪用して、APIを間接的に侵害する可能性があります。

OWASP APIセキュリティプロジェクトの以前のバージョンには、組織に依然として大きな脅威をもたらすその他のいくつかのタイプの攻撃や脆弱性が含まれていました。

• 過度なデータ公開：APIが応答で必要以上のデータを提供すると、過剰なデータ漏えいが発生します。これにより、ユーザーから直接要求されていなくても、機微な情報が攻撃者に意図せず漏えいする可能性があります。
• レート制限の不足：この脅威には、ユーザーが特定の期間に行うことができるリクエストの数を制限しないAPIが含まれます。レート制限がないと、攻撃者は大量のリクエストでAPIを過負荷状態にし、サービス妨害を引き起こしたり、リソースを大量に消費する操作を悪用したりする可能性があります。
• 一括割り当て：一括割り当ては、APIがリクエストからの入力をプログラムオブジェクトに自動的にバインドすることで発生し、攻撃者が意図しないデータフィールドを変更または設定できるようにします。これにより、ユーザーが制御できないはずのデータや設定が不正に変更される可能性があります。
• インジェクション：インジェクション欠陥は、信頼されていないデータがコマンドまたはクエリーの一部としてインタープリターに送信される際に発生します。たとえば、SQL、NoSQL、コマンドインジェクションなどがあります。これらは、APIをだまして意図しないコマンドを実行させることで、データの盗難、損失、破損を引き起こす可能性があります。
• 不十分なロギングと監視：管理者がログを適切に記録してAPIを監視しないと、疑わしいアクティビティが気づかれず、侵害の検知が遅れ、セキュリティインシデントに効果的に対応することが困難になる可能性があります。
• 不適切な資産管理：不適切な資産管理とは、APIのエンドポイントとバージョンを適切に保守および監視しないことを指します。これにより、古いエンドポイント、非推奨のエンドポイント、または安全でないエンドポイントが露出し、攻撃者が悪用する可能性があります。

OWASP Top 10 APIセキュリティリスクやその他の脅威からAPIを保護するために、ITチームとセキュリティチームはAPIセキュリティの多層戦略を展開する必要があります。

このアプローチの中核となるのは、次の4つの主要機能を備えた完全なAPIセキュリティソリューションの展開です。その 4 つとは、API 探索、API セキュリティ体制管理、ランタイム保護、API セキュリティテストです。 

この包括的なアプローチは、API ライフサイクル全体で API を管理してセキュリティを確保する上で、API ゲートウェイやWeb アプリケーションファイアウォール（WAF）といった組織の既存のツールを補完する重要な役割を果たします。

API 探索：ほとんどの組織では、API トラフィックの大部分が可視化されていません。多くの場合、API はすべて API ゲートウェイ経由でルーティングされると想定されているからです。しかし、必ずしもそうではありません。一般的な組織の API の多くは管理されていません（例えば、忘れられているが、依然として動作していて、機微な情報に接している休眠 API など）。インベントリが完全かつ正確なものでなければ、エンタープライズはさまざまなリスクにさらされてしまいます。必要なコア機能は次のとおりです。

• 設定やタイプに関係なく、すべての API を検索してインベントリを作成する
• 休眠 API、レガシー API、ゾンビ API を検知する
• 忘れられているドメイン、見落とされているドメイン、またはその他の不明なシャドードメインを特定する
• 盲点を解消し、潜在的な攻撃経路を明らかにする 

API 体制管理：完全な API インベントリを導入した場合、API を通過するデータフローのタイプを把握し、規制要件への準拠に与える影響を理解することが重要になります。API 体制管理では、トラフィック、コード、設定が包括的に示され、組織の API セキュリティ体制を評価することができます。必要なコア機能：

• インフラを自動的にスキャンして、設定ミスや隠れたリスクを把握する
• カスタムワークフローを作成して、主要関係者に脆弱性を通知する
• 機微な情報にアクセスできる API と内部ユーザーを特定する
• 検知した問題に重大度のランクを付けて、修復の優先順位を設定する

API ランタイムセキュリティ：「データ侵害を想定する」という概念については周知のことでしょう。API 固有の侵入や攻撃は、必然の域に達していると言えます。本番環境で稼働しているすべての API において、攻撃をリアルタイムで検知してブロックできる必要があります。必要なコア機能：

• データの改ざんや漏えい、ポリシー違反、不審なふるまい、API 攻撃を監視する
• ネットワークの変更や面倒なエージェントのインストールを行うことなく、API トラフィックを分析する
• 既存のワークフロー（チケット発行、SIEM など）と統合して、セキュリティ／運用チームに警告する
• 攻撃や悪用をリアルタイムで阻止し、修復の一部または全部を自動化する 

API セキュリティテスト：API 開発チームは、1 秒でも早く作業するよう求められています。あらゆるアプリケーションの開発において、スピードは非常に重要です。しかし、急ぐあまり脆弱性や設計上の欠陥が発生しやすくなったり、検知されないまま進行してしまったりするものです。開発中の API は、本番環境にリリースする前にテストを実施しておくことで、リスクだけでなく、脆弱な API を修正するコストも大幅に軽減することができます。必要なコア機能：

• さまざまな自動テストを実行して、悪性トラフィックをシミュレーションする
• API を本番環境に展開する前に脆弱性を発見し、攻撃が成功するリスクを緩和する
• 定められたガバナンスポリシーやルールに照らして、API の仕様を確認する
• API に特化したセキュリティテストをオンデマンドで、または CI／CD パイプラインの一環として実行する

注：APIセキュリティソリューションに加えて、組織はWebアプリケーションおよび API 保護（WAAP）の機能を検討できます。WAAPは、複数の攻撃ベクトルからの脅威を迅速に特定して緩和するように設計されており、WAFの従来の保護を拡張します。WAFやWAAPと連携するAPIセキュリティソリューションは、ファイアウォールをさらに超えて保護を拡張し、可能な限り強力な防御を構築します。

APIセキュリティアプローチを強化しようとしている組織は、次の手法やテクノロジーを使用することもできます。

認証と認可

• きめ細かい認可の実装：すべてのAPIリクエストが、特定のオブジェクトにアクセスするためのユーザーの権限をチェックするようにします。これらのルールを適用するには、ロールベースのアクセス制御（RBAC）または属性ベースのアクセス制御（ABAC）を使用します。
• 強力な認証メカニズムの使用：多要素認証（MFA）を実装し、OAuth 2.0やOpenID Connectなどの安全なプロトコルを使用してユーザーアイデンティティを検証します。
• 強力なパスワードポリシーの適用：複雑なパスワードを要求し、パスワードローテーションポリシーを適用してセキュリティを強化します。

アクセス制御

• プロパティレベルのアクセス制御：オブジェクト内のプロパティレベルでアクセス制御を適用して、ユーザーが権限を持つプロパティにのみアクセスまたは変更できるようにします。
• 機能レベルのアクセス制御：ユーザーの役割と権限に基づいて、各API機能へのアクセスが制限されるようにします。最小権限の原則を使用してアクセスを最小限に抑えます。

レート制限、スロットリング、リソース監視

• レート制限とスロットルの実行：リソースの枯渇を防ぐために、ユーザーが特定の期間に実行できるAPIリクエスト数に制限を設定します。
• リソースの監視とスケーリング：リソースの使用状況を継続的に監視し、インフラを動的にスケーリングして、可用性を損なうことなく、正当なトラフィックの急増に対応します。

検証とサニタイズ（無害化）

• ユーザー入力の検証とサニタイズ：サーバー側のリクエストのURLやその他の入力が適切に検証され、サニタイズされるようにし、悪性のリクエストを防止します。
• APIレスポンスの検証とサニタイズ：サードパーティAPIからのデータを使用前に検証およびサニタイズすることで、ユーザー入力と同じ検査で処理します。

セグメンテーション

• ネットワークセグメンテーション：サーバー側のリクエストを必要な内部サービスのみに制限し、ネットワークセグメンテーションを使用して潜在的なSSRF攻撃の影響を制限します。

設定とインベントリ

• 環境設定の強化：API設定を定期的に見直して更新し、セキュリティのベストプラクティスに従います。不要な機能やサービスを無効にします。
• セキュリティ設定管理の自動化：自動化されたツールを使用して、すべての環境でセキュリティ設定を一貫して管理および適用します。

テストと監査

• 継続的なセキュリティテスト：APIエンドポイントに脆弱性がないか定期的にテストし、問題を迅速に修正します。
• 定期的な監査：定期的なセキュリティ監査を実施して、認可の欠陥を特定し、修正します。

インベントリ、ドキュメント、レビュー

• APIインベントリの維持：バージョンや使用状況を含め、すべてのAPIエンドポイントの最新のインベントリを維持します。非推奨のエンドポイントが適切に廃止されるようにします。
• APIの文書化と監視：API機能を文書化し、その使用状況を監視して、不適切な管理に関連するセキュリティリスクを検知して緩和します。
• 異常なアクティビティの監視：継続的な監視を行い、ビジネスフローの悪用の試みを示す可能性のある異常なAPI使用パターンを検知し、対応します。
• 定期的なセキュリティレビュー：アクセス制御ポリシーを定期的に見直し、更新して、効果を維持します。
• 安全なライブラリとフレームワークの使用：サードパーティAPIとのやり取りに使用されるライブラリとフレームワークが安全で、定期的に更新されるようにします。

暗号化

転送中のデータの暗号化：Transport Layer Security（TLS）を使用して転送中のデータを暗号化し、機微な情報が攻撃者に傍受されるのを防ぎます。

ファイアウォールとゲートウェイ

• Web アプリケーションファイアウォール（WAF）の実装：Webアプリケーションファイアウォールは、悪性のリクエストをブロックすることで、SQLインジェクションやクロスサイトスクリプティング（XSS）などの一般的なWebベースの攻撃からAPIを保護します。
• API ゲートウェイの使用：API ゲートウェイは、すべての API リクエストのエントリーポイントとして機能し、クライアントの認証、レート制限、トラフィック管理、DDoS 攻撃の防止などのセキュリティタスクをリアルタイムで実行します。

パッチ適用と更新

• パッチ管理：パッチ、アップデート、セキュリティ修正を定期的に適用して、既知の脆弱性に対処します。テスト環境を確立して、パッチによって互換性の問題や意図しない結果が生じないようにします。

ゼロトラスト

• ゼロトラストのアプローチの導入：ゼロトラストのフレームワークは、IT環境の内外のユーザー、デバイス、アプリケーションは本質的に信頼できないことを前提とします。ゼロトラストのアプローチでは、APIへのアクセスをリクエストするすべてのクライアントに継続的な認証と検証を要求することで、不正アクセスを防止し、攻撃が成功した場合の損害を制限します。