WEBサイトスマホアプリを解析してAPIを直接使う攻撃が報告されている。署名や難読化に頼らず、サーバー側で守る ── WebとアプリのAPIの台帳を作って確認する13項目（2026年10月時点）
スマホアプリを解析してAPIを直接使う攻撃が報告されている。署名や難読化に頼らず、サーバー側で守る ── WebとアプリのAPIの台帳を作って確認する13項目（2026年10月時点）
目次
- 01 何が起きたか・いま最新の文書は何か — 公開したアプリは解析される前提で、サーバー側のAPIを確かめる
- 02 なぜ・背景 — アプリは利用者の端末に渡る配布物で、中の鍵は取り出されうる
- 03 用語 — この記事で使う5つの言葉
- 04 型別 — OWASPの項目と照らし、測られていないことを分け、手順を6つに分ける
- 05 WebとアプリのAPIを確かめるチェックリスト
- 06 代替・他の選択肢 — 署名や難読化は補助で、本体はサーバー側の確認にある
- 07 この記事を書くために確かめたことと、確かめていないこと
- 08 このテーマの、これまで — 10月8日の注意喚起から、2週間余りの流れ
- 09 この記事のまとめ
01 何が起きたか・いま最新の文書は何か — 公開したアプリは解析される前提で、サーバー側のAPIを確かめる
2026年10月8日の注意喚起と、10月15日の調査の報告
JPCERT/CCは、2026年10月8日に、国内の複数の組織で相次いだ不正アクセスによる個人情報などの漏えいについて、注意喚起（JPCERT-AT-2026-0030）を公開した。10月15日には、公式ブログ「JPCERT/CC Eyes」で、攻撃に使われた可能性のあるインフラの調査の報告を載せた。注意喚起のページは、10月9日と10月23日にも更新されている。2026年10月23日に、これらのページと、OWASPのAPIセキュリティの文書を開いて読んだ。
結論から書く。スマートフォンのアプリは、配布した時点で、誰にでも解析できる状態になる。アプリを解析して、サーバーのAPI（アプリとサーバーがやり取りする窓口）の場所や鍵を見つけ、アプリを通さずにAPIを直接使う手口が、報告されている。WEBディレクターが確かめることは、アプリの中身を隠すことではなく、サーバー側のAPIが、一つひとつ自分で守れているかである。
JPCERT/CC Eyesが書いた、攻撃元サーバーの調査
報告は、攻撃に使われたサーバーの調査から始まる。JPCERT/CCは、その過程で、攻撃者がAIを利用していたことを確認した、と書いている。
その過程で、攻撃者がAIを利用して、既知の脆弱性のスキャンやAPI経由での攻撃などを実施していたことを確認しました。
調査した攻撃元サーバーは3つに分けて書かれている。1つ目は、Android向けアプリの配布ファイル（APKファイル）を解析し、特定したAPIにSSRFなどの欠陥がないかを調べた痕跡である。2つ目は、Flutterで作られたアプリの解析に使う道具に関連するファイルと、文字列の保存先を示唆する名称のファイルを確認した痕跡である。3つ目は、今回の攻撃とは直接関係しない別のサーバーで、ネットワークの内部への侵入を試みた痕跡である。この記事は、攻撃の道具の使い方や、攻撃元のIPアドレスを書かない。確かめるのは、守る側の項目だけである。
注意喚起が挙げた、API経由の不正な操作
10月8日の注意喚起は、攻撃の類型を複数の「ケース」に分けている。API経由の操作は「ケースB」である。
アプリの管理用APIへの不正なリクエストによって、情報の不正な書き換え等が発生しているものがあります。
手口として挙がっているのは、一般公開しているスマートフォンアプリを解析してAPIの接続先や鍵を特定すること、画面の操作では実行できない内部のAPIを攻撃すること、他のシステムの侵害で盗んだAPIの鍵を使うこと、の3つである（要旨）。画面からは呼べないはずの内部のAPIが、攻撃の対象になっている点に注意したい。
この記事が根拠にした文書と、その日付
| 文書 | 日付（ページの表記） | 使いどころ |
|---|---|---|
| JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」 | 2026年10月15日 | 攻撃元サーバーの調査、推奨する4つの対策 |
| JPCERT/CC 注意喚起 JPCERT-AT-2026-0030 | 公開 2026年10月8日、更新 2026年10月23日 | 攻撃の類型、対策、問い合わせ先 |
| NICT「【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」」 | 2026年10月13日 | アプリの解析を足がかりにした攻撃の説明 |
| マクニカ「相次ぐWEBシステムからの情報漏洩事案について」 | 2026年10月7日（追記 2026年10月8日） | 公表件数、原因の説明の有無 |
| OWASP API Security Top 10（2023年版） | ページに更新日の表記なし（2023年版） | 項目名、確かめる観点、防ぎ方 |
| OWASP REST Security Cheat Sheet | ページに更新日の表記なし | APIキー、管理用の窓口、記録 |
02 なぜ・背景 — アプリは利用者の端末に渡る配布物で、中の鍵は取り出されうる
コンパイルされていても、中の秘密情報は取り出せる可能性がある
JPCERT/CC Eyesの付録は、Flutterで作られたアプリを例に、解析の公開事例を紹介している。報告によると、公開された事例では、アプリの内部に埋め込まれた秘密鍵やAPIの認証の処理が特定され、署名の処理が再現され、正規のアプリを通さずに本番環境のAPIへアクセスできたという。Eyesはそこから、コードがコンパイルされていても、埋め込まれた秘密情報やAPIの認証処理を特定できる可能性がある、とまとめている（要旨）。
推奨の筆頭は、秘密を埋め込まないことである。
秘密情報の保護：APIの認証に使用する秘密鍵や、有効期間の長い認証情報をアプリケーションに埋め込まない。
署名や難読化は、サーバーの守りの代わりにならない
アプリの中で署名を作っても、文字列を読みにくくしても、アプリは利用者の端末の上で動く。端末の持ち主が解析すれば、署名の作り方も、鍵も、読み出せる可能性がある。Eyesが2番目に挙げた対策は、この前提に立っている。
サーバー側での認証・認可：アプリケーション内の署名処理や難読化だけに依存せず、サーバー側で利用者を適切に認証し、操作対象や操作内容に応じた認可を実施する。
認証は「誰か」を確かめること、認可は「その人に、その操作を許してよいか」を確かめることである。署名や難読化は、確かめる材料の1つにはなっても、サーバーが確かめる代わりにはならない。
アプリ自体に欠陥がなくても、サーバー側の不備で漏えいする
NICTの注意喚起も、同じ構図を書いている。
アプリ自体に脆弱性がなくても、バックエンドサーバの認証・認可や入力値の検証などに不備があれば、不正アクセスや個人情報の漏洩につながるおそれがあります。
NICTは、この攻撃を、アプリからバックエンドへの攻撃として「A2B攻撃（App-to-Backend Attack）」と呼んでいる（要旨）。アプリを作った会社の側では「アプリは壊されていない」と見えても、窓口の側の守りが弱ければ、情報は出ていく。
管理する側のシステムも、対象に入っている
10月8日の注意喚起は、一般利用者向けのアプリのほかに、BI（ビジネスインテリジェンス）ツールや従業員向けの管理システムなど、不特定多数の利用者からのアクセスを想定していないシステムも被害に遭っている、と書いている（要旨）。社内向けだから大丈夫、という前提は置けない。台帳には、利用者向けのAPIと、管理用のAPIの両方を載せる。
漏えいの公表は増えているが、原因の説明は少ない
マクニカは、公開情報を集めて、国内の法人が運営するWEBシステムを通じた個人情報の窃取・漏えいの公表件数を数えている。集計の範囲は、2024年1月から2026年10月6日までに公表された事案で、非公開の事案は含まず、同じ委託先の事案は1件にまとめている。
2024年は62件、2025年は84件、今年は10月6日時点で119件となり、合計265件です。
同じ記事は、7月以降に公表された81事案のうち、原因が読み取れる説明があったのは16件（製品などの脆弱性が9件、認証情報の悪用が4件、設定やアクセス制御の不備が3件）で、残る65件（80.2%）は、分類に足る説明がなかった、と書いている（要旨）。公表された件数が増えていても、何が原因だったかは、多くの場合、外から分からない。この数字は、マクニカが定めた範囲での集計であり、日本全体の件数ではない。
AIが使われたかは、文書によって書き方が違う
JPCERT/CC Eyes（10月15日）は、攻撃元サーバーの調査で、攻撃者がAIを利用したことを確認した、と書いた。一方で、マクニカ（10月7日）は、別の範囲について、次のように書いている。
一連の事案でAIが使われたと断定できるログや痕跡は確認されていません。
2つの文書は、日付も、調べた範囲も違う。同じ問いへの食い違う答え、とは読まない。AIが使われたかどうかによって、確かめる項目は変わらない。変わるのは、探される速さである。NICTは、AIの活用によって、アプリの解析や脆弱性の探索が効率化される、と書いている（要旨）。
03 用語 — この記事で使う5つの言葉
API、SSRF、認証と認可、レート制限、API台帳
用語
API：アプリケーション・プログラミング・インターフェース。ここでは、スマートフォンのアプリやWebページが、サーバーに情報を頼んだり、操作を頼んだりするときの窓口を指す。窓口ごとにURLがある。
用語
SSRF（Server-Side Request Forgery）：サーバーが、利用者から渡されたURLの先を取りに行く機能を悪用され、想定していない宛先へ通信させられる欠陥。OWASPの2023年版では、API7に挙がっている。
用語
認証と認可：認証は、利用者が誰かを確かめること。認可は、その利用者に、その対象とその操作を許してよいかを確かめること。ログインできていることは、認証が済んだことを示すだけで、認可が済んだことを示さない。
用語
レート制限：一定の時間に、1つの相手が送れる回数に上限を設けること。OWASPは、API4の防ぎ方の1つに挙げている。
用語
API台帳：Webとアプリが使うAPIを、1つずつ1行に書き出した一覧。この記事の提案で、公式の用語ではない。OWASPのAPI9にある、APIの棚卸し（inventory）の考え方に近い。
04 型別 — OWASPの項目と照らし、測られていないことを分け、手順を6つに分ける
🅰 適用範囲 — WebとアプリのAPIを持つ案件が対象になる
この記事は、WebサイトとスマートフォンのアプリのAPIの両方を持つ案件を想定している。アプリを持たず、WebページだけでAPIも作っていないサイトは、この記事の対象から外れる。ただし、管理画面や、フォームの送信先、ツールが裏で呼ぶ窓口も、APIの一種である。次の表は、OWASPの2023年版の項目のうち、この記事で使う6つを選び、確かめる先に対応づけたものである。
| 項目名（原文のまま） | 訳 | この記事の確かめ先 |
|---|---|---|
| API2:2023 Broken Authentication | 認証の不備 | 05章の4・5・12番目 |
| API4:2023 Unrestricted Resource Consumption | 資源の使用量に制限がない | 05章の9・10番目 |
| API5:2023 Broken Function Level Authorization | 機能単位の認可の不備 | 05章の3番目 |
| API7:2023 Server Side Request Forgery | サーバー側での偽装リクエスト | 05章の7・8番目 |
| API9:2023 Improper Inventory Management | APIの棚卸しの不備 | 05章の1・2・3番目 |
| API1:2023 Broken Object Level Authorization | 対象単位の認可の不備 | 05章の6番目（認可の確認に含む） |
表の項目名は、OWASPのページの表記である。「確かめ先」の列は、この記事の整理で、OWASPの分類ではない。
🅱 その調査が測っていないこと — 自社のアプリが解析できるか、自社のログに痕跡があるか
文書が書いていないことを、3つに分けた。1つ目は、自社のアプリが、実際に解析されうるかどうかである。報告は、他社のアプリや攻撃元のサーバーの話であり、自社のアプリを調べた結果ではない。2つ目は、自社のログに、攻撃の痕跡があるかどうかである。JPCERT/CC（注意喚起とEyes）とマクニカは、確認用のIPアドレスの一覧を載せている。NICTは、IPアドレスを含む詳細をPDFで案内している。一覧のIPアドレスが調査の時点で正規の利用にも使われていた可能性があることも、注意喚起は書いている（要旨）。一覧は、各文書で、最新のものを見る。一覧との一致は、攻撃を受けたことの証明にならない。3つ目は、AIが、どの範囲で使われたかである。02章に書いたとおり、文書によって書き方が違う。
🅲 手順 — 6つの段に分ける
手順は、JPCERT/CC Eyesの4つの対策と、10月8日の注意喚起の対策の項目を、確かめる順に並べ直したものである。6段への分け方は、この記事の提案である。
1段目は、APIの台帳を作る。Webとアプリが呼ぶ窓口を、1つずつ書き出す。2段目は、認証と認可をサーバー側で確かめる。窓口ごとに、誰が、何を、できるかを書く。3段目は、アプリに秘密を埋め込まない。長く使える鍵が入っていないかを探す。4段目は、外のURLを取りに行く機能の宛先を制限する。画像の取り込みやプレビューが当たる。5段目は、回数の制限と、異常の見張りを置く。6段目は、連絡を受ける窓口を決める。JPCERT/CCから連絡が来たときに、誰が受けるかを決めておく。
注意
確かめるのは、自分が運営するサイトとアプリだけにする。他社のアプリを解析したり、他社のAPIに試しの通信を送ったりしない。確かめ方は、自社のコードの確認、設定の確認、自社のログの確認、開発した会社への質問に限る。
05 WebとアプリのAPIを確かめるチェックリスト
下の13項目は、1項目5分ほどでできる作業である。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。コードや設定を見る項目は、開発した会社に聞いてもよい。
- 案件ごとに、Webサイトとアプリが呼ぶAPIのURLを、開発した会社の資料から10本まで書き出す
- 書き出した窓口ごとに、呼ぶのがWebだけか、アプリだけか、両方かを1列で書く
- 画面に出ていない管理用の窓口がないかを、開発した会社に聞き、答えを日付つきで台帳に書く
- 各窓口に、ログインが要るか要らないかを書き、要らない窓口の本数を数える
- アプリの中に、長く有効な鍵や秘密鍵が入っていないかを、開発した会社に聞き、答えを書く
- ログインが要る窓口のうち3本について、他の利用者のデータを呼べない作りかを、開発した会社に聞く
- 画像の取り込みやURLのプレビューなど、外のURLを取りに行く機能を、台帳から探して数える
- 外のURLを取りに行く機能について、宛先の許可リストと、転送先の確認があるかを、開発した会社に聞く
- ログイン、パスワードの再設定、検索の3つの窓口に、回数の制限があるかを書く
- 直近1か月のアクセスログを開き、同じ接続元からのAPIへの大量のアクセスと、エラー応答の急な増加がないかを、日付で3つ書く
- JPCERT/CCの注意喚起とマクニカの文書にある確認用のIPアドレスの一覧を最新の版で開き、自社のログに同じ接続元があるかを数える
- 鍵やトークンが漏れたときに、無効にできる人と手順を、1行で書く
- JPCERT/CCから連絡が来たときに受ける人を1人決め、その人の連絡先を台帳に書く
時間がないときは、項目1・4・5・13の4つだけでも、状況はつかめる。
06 代替・他の選択肢 — 署名や難読化は補助で、本体はサーバー側の確認にある
API台帳の列は、7つで足りる
台帳は、表計算の1枚で足りる。窓口1つにつき、1行を書く。列は、次の7つにした。窓口のURL、呼ぶ側（Webだけ・アプリだけ・両方）、ログインが要るか、認可の確かめ方、外のURLを取りに行くか、回数の制限があるか、担当者、である。列を増やすほど更新されなくなるので、まずこの7列で始め、足りない列は埋めながら足す。この列の選び方は、この記事の提案である。
守り方を、効くことと効かないことで並べる
次の表は、アプリとAPIの守り方を、文書が書いた範囲で並べたものである。「効くこと／効かないこと」の列は、この記事の整理である。
| 守り方 | 文書の書き方 | 効くこと／効かないこと（この記事の整理） |
|---|---|---|
| 署名・難読化 | Eyes：これらだけに依存せず、サーバー側で認証・認可する | 解析を遅らせる補助にはなるが、鍵が端末に入っていれば、サーバーの守りの代わりにならない |
| サーバー側の認証・認可 | Eyes：利用者を認証し、操作対象と内容に応じて認可する。注意喚起：各APIで、許可された利用者とHTTPメソッドだけを受け付ける | 守りの本体。窓口ごとに確かめる必要がある |
| 有効期限のあるトークン | 注意喚起：適切な有効期限を設け、長期間有効なトークンを避ける | 漏れたときの被害の長さを短くする。漏れること自体は防がない |
| レート制限 | 注意喚起：単位時間あたりの件数を制限する。OWASP：APIの種類ごとに調整する | 大量実行を遅らせる。1回の不正な操作は防がない |
| 宛先の許可リスト | Eyes：アクセス先を制限し、リダイレクト後の宛先も検証する | SSRFを減らす。取りに行く機能を持たないのが最も確実 |
| 公開の停止 | 注意喚起：業務上必要のない機能がインターネットに公開されているなら、公開を停止する | 使っていない窓口を閉じれば、確かめる対象が減る |
外のURLを取りに行く機能は、宛先を許可リストにして、転送を止める
OWASPは、API7の防ぎ方の中に、許可リストと転送の扱いを挙げている。
Disable HTTP redirections.
（訳: HTTPのリダイレクトを無効にする。）
防ぎ方の他の項目は、取りに行く機能をネットワークの内側から分けること、受け取ってよい取得元・通信方式・ポート・メディアの種類を許可リストにすること、などである（要旨）。Eyesの推奨にある「リダイレクト後の宛先も検証する」は、転送を無効にできない場合の、次善の項目と読める。ただし、この読み方は、この記事の整理である。
回数の制限は、窓口ごとに調整する
OWASPのAPI4は、回数の制限を、防ぎ方に挙げている。
Implement a limit on how often a client can interact with the API within a defined timeframe (rate limiting).
（訳: 決められた時間の中で、クライアントがAPIとやり取りできる頻度に上限を設ける（レート制限）。）
続けて、制限は事業の必要に合わせて調整し、窓口によっては、より厳しい方針が要る、とも書いている（要旨）。注意喚起も、ログイン、パスワードの再設定、SMSの送信、検索など、負荷や悪用の危険が高い機能には、個別に制限を設けるよう書いている（要旨）。05章の9番目は、その3つを確かめる。
APIの台帳は、古い版や試験用の窓口まで載せる
OWASPのAPI9は、棚卸しの不備を挙げ、防ぎ方の1つに、次を書いている。
Use external protection measures such as API security specific solutions for all exposed versions of your APIs, not just for the current production version.
（訳: APIに特化した解決策などの外側の保護を、現在の本番の版だけでなく、公開されているすべての版のAPIに使う。）
API9の例には、本番のAPIには回数の制限があるが、同じ機能を持つ試験用の窓口には制限がなく、そこから突破された場面が出てくる（要旨）。台帳には、いま使っている窓口だけでなく、古い版や試験用の窓口も書く。見つかった窓口は、止めるか、本番と同じ守りを足す。
管理用の窓口は、インターネットに出さない
OWASPのREST Security Cheat Sheetは、管理用の窓口について、最初にこう書いている。
Avoid exposing management endpoints via Internet.
（訳: 管理用の窓口を、インターネットに出すのを避ける。）
出す必要がある場合は、多要素認証などの強い認証を求め、アクセスを制限する、とも書いている（要旨）。同じ文書は、APIキーについて「機密性や価値の高い資源を、APIキーだけで守らない」と書いている（要旨）。鍵があることと、守られていることは別である。
JPCERT/CCから連絡が来たときの窓口を決める
Eyesは、報告の最後に、攻撃の標的になっている可能性がある組織を見つけた場合は、その組織に連絡している、と書いている。
JPCERT/CCから連絡を受けた際は対応をお願いいたします。
連絡を受ける人が決まっていないと、知らせが届いても止まる。05章の最後の項目で、受ける人を1人決める。インシデントの相談先は、10月8日の注意喚起の末尾に書かれている。
07 この記事を書くために確かめたことと、確かめていないこと
開いたものと、読み方
2026年10月23日に、01章の表の文書を開いた。引用した日本語の文と英文は、開いたページの本文と機械で照らし、すべて一致した。照らせなかった文は、引用の形にしていない。OWASPの2つのページは、更新日の表記が見当たらなかったので、日付は書いていない。IPアドレスの一覧は、各文書に載っているが、この記事には写していない。
確かめていないこと
4つある。1つ目は、PDFの詳細版である。NICTのページは、攻撃手法の詳細をPDFで案内しているが、PDFの本文は開いていない。2つ目は、JPCERT/CC Eyesが紹介している、解析の公開事例の元の記事である。Eyesの記述を要旨として書いた。3つ目は、マクニカの集計の元の事案である。件数は、マクニカの数え方のまま書いた。4つ目は、各APIの個別の実装である。ここで書いたのは確かめる項目までで、直し方は案件ごとに違う。
当サイトの運営の記録
当サイトの窓口の名前、数、守りの設定、鍵の置き場所は、この記事に書かない。
数え方の限界
6段の分け方、台帳という呼び方、守り方の表の最後の列は、この記事の整理で、公式の分類ではない。台帳が埋まっても、そのAPIが安全だとは言えない。台帳は、知らせが来たときに、どの窓口が該当するかを、数分で答えるための道具である。ログを見て「異常がなかった」と書くときは、見たログの範囲を一緒に書く。記事「「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直した」と、記事「AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた」は、その形を扱った。
08 このテーマの、これまで — 10月8日の注意喚起から、2週間余りの流れ
2026年10月8日から23日までの流れ
開いた文書の日付を並べると、次のようになる。10月7日にマクニカが、国内のWEBシステムからの情報漏えいをまとめて公開した。10月8日にJPCERT/CCが注意喚起を出し、10月9日に追記した。10月13日にNICTが、アプリの解析を足がかりにした攻撃への注意喚起を出した。10月15日にJPCERT/CC Eyesが調査の報告を載せ、10月23日に注意喚起が更新された。2週間余りで、書かれた中身は「脆弱性の話」から「APIと鍵の扱いの話」へ広がった。この並びは、日付を並べたものであり、文書どうしの関係を示すものではない。
当サイトでこの周辺を扱った記事
記事「Cloudflareは、ログインと会員登録の異常をアカウント単位で調べる画面を先行利用の顧客に出した ── 同じ問いを自社の記録に当てて確認する13項目（2026年10月時点）」は、ログインの異常を、自社の記録で確かめる項目を扱った。05章の9番目と10番目に近い。記事「Googlebotの名乗りは誰でも書ける。通す・止めるを名乗りだけで決めず、接続元で確かめる ── 自分のサイトの判定を点検する13項目（2026年10月時点）」は、名乗りと接続元の食い違いを扱った。APIへの大量のアクセスの接続元を見るときの考え方に通じる。
ブログの記事「Cloudflareが通信の半分以上は人間ではないと書いた週、当サイトのログで自動と分かるものは36.2%だった ── 他人の大きな数字を、自社のログ1週間分で数え直す」は、自動のアクセスをログで数える方法を、ブログの記事「Cloudflareが確認済みのボットを「行儀」で評価し始めた週、当サイトの9つの名乗りの取得（4,317行）の18.1%は、公式のIPアドレスの一覧と合わなかった ── 14日分のログで数え直した」は、公式の一覧と照らす方法を扱った。
AIが作ったコードと、鍵の扱い
ブログの記事「AIエージェントのコードに脆弱性が見つかった日 ── 発見と修正の記録」は、AIの周りのコードの欠陥を扱った。今回の報告にある「AIによる探索」とは別の話だが、人が見落とす欠陥を、機械が速く探すという点は共通している。
現在の貴方のIPアドレス
このサイトで書いている人
