相次ぐ不正アクセスから見えてきた「API攻撃」とF5XCによる対策
最近の不正アクセス事例では、Webサイトやアプリの裏側にあるAPIを狙った攻撃が確認されています。最新の注意喚起をもとに、その攻撃と対策について考えてみます。
みなさん
こんにちは。あつふみです。
ここ最近、不正アクセスや情報漏えいのニュースを毎日のように聞くようになりました。
ニュースを見るたびに「また情報漏えいか……」と思っていましたが、最近の事例を詳しく見てみると、「API」が攻撃の入口になっているケースもあるようです。
今回は、最近起きている不正アクセスや情報漏えいの概要を整理し、その対策について考えてみたいと思います。
※本ブログは2026年10月15日の情報をもとに記載しております。
JPCERT/CCが示した4つの攻撃ケース
2026年10月8日に、JPCERT/CCから「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」が公開されました。
その中で今回注意喚起で紹介されたケースを以下に簡単に整理してみます。
ケースA:さまざまな脆弱性や設定不備を探す
公開されているシステムに対して既知の脆弱性を探索するほか、環境設定ファイルやバックアップファイルの窃取などが試みられている可能性が示されています。
ケースB:APIを不正に利用する
公開されているスマートフォンアプリからAPIのエンドポイントやキーを特定し、本来の画面操作では実行できない内部APIへのアクセスなどが試みられています。
ケースC:脆弱性をAPI経由で悪用する
MetabaseのSQLインジェクション脆弱性「CVE-2026-72898」を、APIへの不正なリクエストを通じて悪用するケースです。
ケースD:侵害したサーバーにWebシェルを設置する
公開Webサーバーからアクセス可能なアプリケーションサーバー上にWARファイルが設置され、その中のJSPファイルがWebシェルとして動作する事案も確認されています。
ケースA〜Dは、それぞれ攻撃の手法や段階が異なります。
ケースAは、公開システムの脆弱性や設定不備などを探す攻撃です。
またケースDは、何らかの方法で侵害された環境にWebシェルが設置された事例です。
一方で、ケースBとCは、攻撃経路として「API」が具体的に登場しています。
ケースBではAPIそのものの不正利用、ケースCではAPIを経由した脆弱性の悪用が確認されており、異なる攻撃でありながら、どちらにも「APIが攻撃経路として利用されている」という共通点があります。
最近の攻撃者は、普段利用者からは見えにくい、Webサイトやアプリの「裏側」にあるAPIを直接狙っているようです。
さらに気になったのが、この注意喚起から数日後、NICT(国立研究開発法人情報通信研究機構)からもAPIに関連する攻撃について注意喚起が公開されたことです。
その内容は、公開されているAndroidアプリを解析し、そこから得られた情報をもとにバックエンドを攻撃する「A2B攻撃(App-to-Backend Attack)」でした。
NICTも注意喚起。「A2B攻撃」とは?
JPCERT/CCの注意喚起から数日後の2026年10月13日 「相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」が公開されました。
NICTでは、一般公開されているAndroidアプリを解析し、その情報を利用してアプリのバックエンドサーバーを攻撃する手法を、
A2B攻撃(App-to-Backend Attack)と呼んで注意喚起しています。
次の図は、公開されているページに載っている図となります。

簡単に説明すると、
攻撃者はまず公開されているアプリを解析し、「このアプリはどこに、どんなAPIで通信しているのか」を調べます。
そして、その情報を手掛かりにAPIへ直接アクセスし、バックエンド側に存在する脆弱性を狙います。
つまり、
「スマートフォンアプリを攻撃する」のではなく、「アプリを手掛かりにAPIの接続先や仕様を特定し、そのAPIを攻撃する」
という点がポイントです。
NICTは、アプリ自体に脆弱性がなくても、バックエンドサーバー側の認証・認可や入力値検証などに不備があれば、不正アクセスや個人情報漏えいにつながるおそれがあるとしています。
API をどう守るか
JPCERT/CCもNICTとしては、対策として、
- 公開APIやサーバーの洗い出し
- 不審なアクセスや情報の不正取得の確認
- IDOR/BOLA、SSRF、RCE、SQLインジェクションなどの点検
- 不要なAPIの停止
- アクセス制限
- 監視の強化
などを挙げています。
ここで重要なのは、最初に「公開APIを洗い出す」ことが挙げられている点だと思います。
そもそも、
「自社で公開されているAPIをすべて把握できていますか?」
という話です。
Webサイトの裏側、スマートフォンアプリ、ECサイト、会員サイト、外部サービスとの連携など、現在のシステムではさまざまな場所でAPIが使われています。
その中に、
- 昔作ったAPI
- 開発部門しか把握していないAPI
- 使われなくなったAPI
などが残っていたらどうでしょうか。
存在を把握できていないAPIは、守ることも難しくなります。
F5 XC のAPI Securityで対策「APIを見つける・守る」
そこで活用できるのが、F5 Distributed Cloud(F5 XC)のAPI Securityです。
API Securityは、主にAPI DiscoveryとAPI Protectionの2つの機能があります。
API Discovery
API Discoveryでは、まずAPIを可視化し、どのようなAPIが利用されているのかを把握するということができます。
「どのようなAPIが存在するのか」
「把握していないAPIが公開されていないか」
「APIがどのように利用されているのか」
というところをまず把握したうえで、どうやって守っていくかということが重要です。
API Protection
APIの全体像を把握したら、次に必要になるのが「APIをどう守るか」です。
例えば、
- 想定していないクライアントからのアクセス
- 不正な形式や内容のリクエスト
- 本来必要のないAPIへのアクセス
- 把握していなかったAPIの公開
などを確認し、必要な通信は許可し、不正・不要な通信は制御するという考え方です。
APIを把握するだけで終わらせず、不正なアクセスや想定していない利用からAPIを保護していくことが重要です。
API DiscoveryやAPI Protectionは、過去に紹介している記事もありますので、こちらもぜひご参照ください。
まとめ
Webサイトやスマートフォンアプリの裏側では、当たり前のようにAPIが利用されています。
一方で、すべてのAPIを把握し、適切に管理できているかというと、意外と難しいのではないでしょうか。
今回紹介したA2B攻撃のように、公開されているアプリを手掛かりとしてAPIの接続先や仕様を調べ、バックエンドを狙う攻撃もあります。
だからこそ、APIを守るためには、WAFなどで攻撃を防ぐだけではなく、「まず、自分たちがどのようなAPIを公開しているのかを把握する」ことが重要だと感じました。
F5 XCのAPI Securityでは、API DiscoveryでAPIを見つけ、API Protectionで守るという考え方で対策できます。
「自社で公開しているAPI、本当にすべて把握できているかな?」
今回の記事が、そんなことを一度考えてみるきっかけになればと思います。




