すべてのCISOが知っておくべきAPIセキュリティの3つのポイント

F5 ADSP | 2025年9月30日

In the third episode of the F5 Global CISO: For defenders by defendersの第3回では、私が特に信頼を寄せるAPIハッカーの1人であるCorey Ball氏をゲストに迎えました。Corey氏は過去15年間にわたりITとサイバーセキュリティの分野で活躍しています。このテーマに関する知見がほとんど体系化されていないことに気づき、APIハッキングについて文字どおり「本を書いた」人物でもあります。私たちが初めて出会ったのも、その頃でした。

その書籍とは、『Hacking APIs: Breaking Web Application Programming Interfaces,』です。Web APIのセキュリティテストを短期間で学べる内容となっています。Coreyは、APIセキュリティについて無料で学べるリソースであるAPIsec University,の創設者の1人でもあり、APIセキュリティテストとWebアプリケーションのペネトレーションテストを実施するhAPI Labs,の創設者兼CEOでもあります。

今すぐ聴く

私のポッドキャストの最新エピソードをぜひお聴きください：

エピソード3：「AI時代のAPIセキュリティ」
エピソード4：「シンプル化とセキュリティ強化：CXO向けサイバーセキュリティ戦略の要点」

Corey氏がAPIセキュリティの専門家であることは明らかです。そこで、今回のテーマについて尋ねました。「APIセキュリティに関して、すべてのCISOが知っておくべき3つのことは何でしょうか」。特に、攻撃者の視点からAPIセキュリティを見ることで、防御側は何を学べると考えているのかを聞きました。

ヒント1：APIセキュリティテストツールをテストする

APIは、世界で最も価値のある資源の1つであるデータを転送するための基盤技術です。Corey氏は次のように述べています。「このデータを保護するために、ファイアウォールやWebアプリケーションファイアウォールなどの防御層を設けています。しかし、インターネットに公開されているAPIは、侵害の入り口となることが少なくありません。認証が不要で、認可も適用されていないセキュリティ対策の不十分なAPIがあると、犯罪者に直接的な侵入口を与えることになります。犯罪者はそこから侵入して不正なリクエストを行い、ほかのあらゆる防御層で保護されているデータを盗み出す可能性があります。」

「防御側の担当者には、APIセキュリティのテストに適切なツールと手法を使用する必要があることを、しっかり理解してもらいたいと思います」と彼は述べました。自動スキャナーでAPIをスキャンし、問題なしというレポートが出たからといって、すべて安全だと考えるだけでは不十分です。防御側の担当者は、APIリクエストを能動的にテスト、分析して実際の問題を明らかにし、存在するセキュリティ上の問題に対処する必要があります。

テスト担当者をテストする。Corey氏によると、テストのスキルとツールを検証する実践的な方法の1つは、意図的に脆弱性を組み込んだアプリケーションを使って練習することです。こうしたアプリケーションは、安全な演習用に設計されたターゲットであり、テスト担当者は一般的なAPIセキュリティ問題を体験し、再現して、理解できます。「たとえば、OWASP API Security ProjectはcrAPIを提供しています。これは、APIセキュリティの指導、学習、演習を目的として、意図的にAPIの脆弱性を多数組み込んだトレーニングツールです。crAPIにスキャナーを直接実行し、どのような結果が得られるかを確認できます」。HSTSヘッダーの欠落やクリックジャッキング対策の設定ミスなど、表面的な脆弱性しか見つからない場合、テストツールは、OWASP API Top 10に挙げられているような、より深刻なAPIの脆弱性を見落としている可能性があります。「これは、テストツールが考えているほど効果的ではない可能性を示しています」とCorey氏は述べています。

ヒント2：WAFとAPIゲートウェイだけではAPIを保護できない

Coreyと私は、従来のエンタープライズ向け脆弱性ツールや管理プログラムがAPIには通用しないことについても話し合いました。APIは、従来のWebアプリを標的とする攻撃とは異なる種類の攻撃に対して脆弱だからです。たとえば、オブジェクトレベルの認可不備（BOLA）やオブジェクトプロパティレベルの認可不備（BOPLA）は、APIの中核となるビジネスロジックに関連するAPIセキュリティ上の欠陥です。そこでCoreyに、企業がWAFとAPIゲートウェイを導入している場合、APIを保護するうえで何が不足しているのかを尋ねました。

WAFとAPIゲートウェイは、アプリのセキュリティとユーザー認証に不可欠ですが、それだけではAPIを保護するには不十分だとCorey氏は述べています。APIのセキュリティ確保における最大の課題は認可です。つまり、ユーザーがアクセス、閲覧、変更、削除できるのは、自分自身のデータだけであることを保証する必要があります。「ユーザーAが操作できるのは、ユーザーA自身のリソースだけでなければなりません。ユーザーBのリソースを変更、読み取り、更新、削除できないようにする必要があります」と同氏は述べています。「APIにおける認可は、間違いなく困難な課題です。きめ細かな認可ルールが設定されていなければ、犯罪者が他人のリソースを要求しても、正当なリクエストとほとんど見分けがつきません」

認可制御は、複数の相互補完的な制御を組み合わせる多層的なAPIセキュリティアプローチの一部として実装し、1つの層が機能しなくても、他の層で保護を継続できるようにする必要があります。

ヒント3：生成AIのセキュリティ確保には追加の保護対策が必要

組織が生成AIやAI搭載アプリへの投資を拡大する中、これらのテクノロジーによってAPIの攻撃対象領域が広がることを理解する必要があります。生成AIアプリケーションは、基盤に至るまでAPIで構成されているためです。つまり、AIの世界はAPIの世界でもあります。生成AIアプリの基盤構造はAPIに大きく依存しており、AIシステムのほぼすべての部分が、これらのインターフェースを通じて外部に公開されています。

しかし、Coreyと私が話し合ったように、APIはAIアプリとアーキテクチャを保護するうえでの課題の一部にすぎません。AIエンジンや大規模言語モデル（LLM）にも、攻撃に悪用される可能性のある別の脆弱性があります。たとえば、Model Context Protocol（MCP）は、LLMを外部のツールやサービスに接続するための統一されたフレームワークを提供するオープンソース標準です。MCPには、AIをアプリに統合するうえで多くのメリットがある一方、重大なセキュリティ上の課題もあります。Coreyは次のように述べています。「生成AIの舞台裏を見ると、すでに多数のAPIで構成されています。そこにMCPが導入されますが、MCPは認証と認可の制御が脆弱なため、攻撃を受けやすいことが少なくありません。ただし、セキュリティ対策も追いつきつつあります」

MCPに関するもう1つのセキュリティ上の考慮事項は、プロンプトインジェクション攻撃と自然言語を悪用したハッキングです。「企業を代表するAIエージェントやチャットボットを使用する場合、こうした攻撃がビジネスリスクにつながる可能性があります。攻撃者はAIエージェントを操作し、企業のイメージを損なう不適切な発言をさせたり、チャットボットを誘導して承認されていない割引を提供させたりすることができます」。また、組織は、チャットボットが企業の法的な代理人と見なされ、その発言や行為について企業が法的責任を問われる可能性があることも理解する必要があります。企業には慎重な対応が求められます。AIアプリがもたらすビジネス機会を逃すことなく、同時にデューデリジェンスを実施し、AIアプリやチャットボットが正確なデータでトレーニングされ、プロンプトインジェクションから保護されていることを確認する必要があります。

Coreyと近況を語り合うのはいつも楽しいものです。今回は、攻撃者の視点からセキュリティを見ることで防御側が何を学べるかについて話し合う機会をいただき、Coreyに感謝します。防御側は攻撃の実態を踏まえて防御策を講じる必要があります。そのため、攻撃の仕組みや攻撃者の狙いを理解し、限られたリソースを適切に配分して、企業、省庁、行政機関に適した多層防御を構築することが重要です。