OWASP トップ 10 API セキュリティリスク：2023 年版がついに登場
最新のアプリケーション・プログラミング・インターフェース（API）を使用すると、ほぼすべてのソフトウェア、デバイス、データソース間での柔軟かつ迅速な連携が可能になります。API はさまざまな機能を果たし、イノベーションとデジタルトランスフォーメーションの基盤を提供します。
API は、特にマイクロサービスベースのアーキテクチャへの移行が進む中においては、最新のアプリケーションの構築と接続の事実上の標準にもなっています。システム間のデジタルグルー（接着剤）として機能する API には、適切なセキュリティを確保することが重要です。
API コールごとにセキュリティホールやプライバシーリスクが発生する可能性があり、その原因はデータ検証の不備、設定エラー、実装の欠陥、セキュリティコンポーネント間の統合不足など多岐にわたります。このことは、Open Web Application Security Project（OWASP）トップ 10 API セキュリティリスクで定義されている脆弱性に対処する際に覚えておく必要があります。
2023 年 6 月 5 日に OWASP が発表した 最初のメジャーアップデート は、2019 年にリリースされた最初のリストを更新したものです。今回のブログでは、その変更点をご紹介します。現在の API 脆弱性に影響を与えている主な要因を確認して、適切な情報に基づく API のセキュリティ確保にお役立てください。
OWASP トップ 10 API セキュリティリスク
OWASP は、セキュリティに関する注意喚起文書を作成している民間組織です。その基となるコミュニティーからのフィードバックや専門家の評価には、Akamai も貢献しています。これらの文書は、今日の組織で見られる最も一般的な脆弱性について説明したもので、開発者から CISO まで API に関係するすべての人にとって優れたリソースです。
OWASP は、 トップ 10 API セキュリティリスク の文書を他のトップ 10 リストとは別に発表しています。それによって強調しているのは、 API セキュリティ には独自のアプローチが必要であるということです。この OWASP API Security Project では、API 固有の脆弱性とセキュリティリスクを理解して緩和するための戦略とソリューションに焦点を合わせています。
それらの違い
2019 年版と 2023 年版の違いを見てみましょう（図 1）。
図 1：2023 年版 OWASP トップ 10 API セキュリティリスクの変更点
2023 年版の OWASP トップ 10 API セキュリティリスクは、ペースの速い業界の先を見通した注意喚起文書です。他のトップ 10 に代わるものではありません。今号の内容は次のとおりです。
- 「過度なデータ公開」と「一括割り当て」を統合し、一般的な根本原因であるオブジェクト・プロパティ・レベルの認可の検証失敗に焦点を合わせました。
- リソース消費に重点を置き、リソース枯渇のペースをさらに重視しています。
- 新しい脅威に対応するため、新たに「機密性の高いビジネスフローへの制限のないアクセス」カテゴリーを作成しました。これには、レート制限を使用して緩和できる脅威のほとんどが含まれます。
- 最近、ターゲットの API への直接攻撃よりも、ターゲットの統合サービスへの侵害が増えてきています。そのため、「API の安全でない使用」を追加しました。今こそ、この高まるリスクについて注意を喚起するときです。
新規のカテゴリーとリストイン／リストアウトしたカテゴリー
新規 | API3:2023 | オブジェクト・プロパティ・レベルの認可の不備
OWASP は、以前の「過度なデータ公開」カテゴリーと「一括割り当て」カテゴリーを統合して、新たに「 オブジェクト・プロパティ・レベルの認可の不備（BOPLA）」カテゴリーを作成しました。一般的な根本原因であるオブジェクト・プロパティ・レベルの認可の検証失敗に焦点を合わせています。
オブジェクトレベルの認可の不備（BOLA）と BOPLA の違いは、BOLA はオブジェクト全体を指し、BOPLA はオブジェクト内のプロパティを指していることです（図 2）。
図 2：オブジェクト内のプロパティを指す BOPLA
オブジェクトレベルの大きなリスクは OWASP でも Akamai でも発見が続いており、BOLA は依然として最初に注意を喚起する必要のある最も重大な API セキュリティリスクです。
しかし、さらに 1 段階掘り下げてオブジェクト・プロパティ・レベルを見ると、別のリスクも存在します。情報が過度に共有されるリスクや、変更または削除すべきでないプロパティが変更または削除されるリスクです。
BOLA に対応していても、BOPLA に対応しているとは限りません。「一括割り当て」と「過度なデータ公開」を 1 つのカテゴリーにまとめることで、オブジェクト内のプロパティに対して API 開発者が必要とする注意が強調されます。
この区別は、API セキュリティ製品を選択するユーザーにとって重要です。これにより、ユーザーは製品が両タイプの攻撃に対応していることを確認できます。
リストイン | API6:2023 | サーバーサイド・リクエスト・フォージェリ
OWASP は、インジェクションのセキュリティリスクの重大度を下げてトップ 10 から外し、代わりに サーバーサイド・リクエスト・フォージェリ（SSRF） を追加しました。
SSRF は、攻撃の一種です。この攻撃では、Web アプリケーションや API の脆弱性を悪用して、サーバーから他の内部システムまたは外部システムに不正なリクエストを送信します。
OWASP がこの変更を選択した理由として、次のようなことが考えられます。
- API は、HTTPS API ベースの通信プロトコルを使用する Kubernetes や Docker などの最新テクノロジーを採用しているため、SSRF 攻撃を受けやすくなっています。
- API エンドポイントを介した Webhook、SSO 統合、URL ファイルフェッチ／リダイレクトなどのテクノロジーにより、攻撃者は SSRF を実行する機会を得ています。
その詳細
SSRF 攻撃の詳細については、Mike Elissen のブログで サーバーサイド・リクエスト・フォージェリ（SSRF）攻撃を可能にしている API に関する投稿をご覧ください。
リストアウト | API8:2019 | インジェクション
インジェクション攻撃をリストから外すことは API セキュリティコミュニティー内で議論を呼ぶ大きな動きでしたが、API エンドポイントに対するインジェクション攻撃の脅威は減少しています。
インジェクションについては、今後は基本的に API8:2023 | セキュリティ設定のミスに含まれることになります。適切なセキュリティ設定には、Web アプリケーションと API の保護メカニズムを含める必要があります。デフォルトでインジェクションをスキャンして阻止するメカニズムです。
GraphQL は、API テクノロジーとして発展しています。このクエリー言語はインジェクション攻撃を再び増加させる可能性が根底にあるため、GraphQL を使用する API 開発者は引き続き警戒を怠らないでください。
新規 | API4:2023 | 制限のないリソース消費
元のリストで具体的に焦点を合わせていたのは、ユーザー体験を損なう API エンドポイントの過負荷（および使用できない可能性）につながるリソース消費のリスクを理解することでした。
最近の API エンドポイントには可用性が求められますが、使用可能であるだけでは不十分です。API ゲートウェイ、負荷分散、レート制限制御などを実装すると、正しい方向に進むことができます。
近年、「API 使用の経済性」が大きく変化しています。この 更新されたカテゴリー の目的は、サードパーティーの API 統合によって拡大し続けるこうした側面に対する注意を喚起することです。
新規 | API6:2023 | 機密性の高いフローへの制限のないアクセス
もう 1 つの新しい追加は、 API6:2023 機密性の高いフローへの制限のないアクセスです。このカテゴリーでは、セキュリティを強化する方法をついに成文化しました。それはつまり、攻撃者の考えをより深く理解し、潜在的な利益がどこにあるかを把握することです。
テクノロジー（API）は、ビジネスロジックを実行するための単なる手段です。テクノロジーによるビジネスロジックのバイパスや変更は望ましくないことであり、複雑化の原因になる可能性があります。
OWASP は、こうした複雑化を防ぐ方法の具体例を紹介しています。ただし、このセキュリティリスクは、API エンドポイントがサポートするビジネスロジックにまさに固有のものです。
API 開発者：例
Mike Elissen は最近、ストリーミングサービスの API 開発者と話をしました。このストリーミングサービスでは、新しい視聴者を獲得するために、クレジットカード情報を入力した新規ユーザーに 30 日間の無料トライアルを提供しました。
しかし、ビジネスロジックでチェックしたのは、新規申し込み時のメールアドレスの一意性のみでした。新しいメールアドレスを使うと、同じクレジットカード情報で新しいトライアルを簡単に利用できました。つまり、新しいアカウントを毎月作成すれば、サービスをいつまでも無料で利用できてしまうのです。
新規 | API10:2023 | API の安全でない使用
サードパーティーの API 使用 が急増しているため、多くの API は内部および外部（サードパーティー）のさまざまなサービスと統合して通信し、データを送受信する必要があります。
こうした場合にも、セキュリティの「基本」ルールに従うことが重要です。この領域でのセキュリティ製品による脆弱性検知とプロアクティブな防御は困難になる可能性があります。
OWASP の文書には、次のような一般的な提案と API 固有の提案の両方が含まれています。
- リダイレクトを注意深く追ってください。この管理体制をビジネスロジックに組み込むとともに、トラフィックフローを継続的に監視および検査するセキュリティソリューションを追加してください。
- サードパーティー API は、評判が良くても、簡単に信頼しないでください。アプリケーションと API エンドポイントに防御と制限を構築してください。
API セキュリティを支援する Akamai
組織とそのセキュリティベンダーは、緊密に連携し、人、プロセス、テクノロジー全体を調整して、 OWASP トップ 10 API セキュリティリスクに記載されているセキュリティリスクに対して強固な防御策を講じる必要があります。
Akamai は、業界をリードするセキュリティソリューション、経験豊富なエキスパート、 Akamai Connected Cloudを提供し、毎日、数百万件の Web アプリケーション攻撃、数十億件のボットリクエスト、数兆件の API リクエストから知見を収集しています。Akamai の Web アプリケーションおよび API セキュリティソリューションは、最先端の Web アプリケーション攻撃、分散型サービス妨害（DDoS）攻撃、API ベース攻撃から組織を保護します。
Akamai + Neosec
OWASP の新しいリリースと同じ時期に、Akamai が最近買収したのが Neosecです。Neosec の API セキュリティソリューションは、市場をリードする Akamai のアプリケーションおよび API セキュリティポートフォリオを補完し、急拡大する API 脅威の状況に対する Akamai の可視化能力を大幅に強化します。
この組み合わせは、お客様が API を簡単に保護できるように設計されています。すべての API の検出、リスクの評価、脆弱性や攻撃への対応を支援します。
詳細について
詳細については、 Akamai の API セキュリティソリューション と Neosec の買収をご覧ください。
おめでとう、そしてありがとう、OWASP！
セキュリティに関する注意を喚起するためには、コミュニティーの多大な努力が必要です。このプロジェクトを主導した OWASP に感謝します。Erez Yallon 氏、Inon Shkedy 氏、Paulo Silva 氏には 2023 年版で素晴らしい仕事を成し遂げていただきました。ありがとうございます。
そして、すべての貢献者にも感謝します。特に、Akamai の Maxim Zavodchik と Mike Elissen は、このプロジェクトに参加して広範な開発者コミュニティーに API セキュリティの知識を広めてくれました。
API に関する追加情報
Akamai は、API 使用状況と API トラフィック量をインターネットの現状（SOTI）レポートの一環として追跡しています。こちらから 以前の SOTI レポート で詳細をご確認いただけます。新しい SOTI レポートは四半期ごとに公開されます。
その他のリソース
動画シリーズ： API セキュリティの基礎
