どうやら報告を見るに2003年に相応しい最先端で高度などこかで見たみた攻撃手法が開発されたようだ
革命的な新攻撃、その名も「HTTPリクエストの送信」
2026年10月、NICTは公開Androidアプリの解析結果を利用してバックエンドを攻撃する手口を「A2B攻撃（App-to-Backend Attack）」と名付けた。JPCERT/CCも、APKの解析、APIの直接操作、権限変更や不正アカウント作成などの報告を公表している。
何より衝撃的なのは、その説明から浮かび上がる防御側の古典的な失敗だ。
アプリを解析し、APIのURLを見つけ、HTTPリクエストを書き換える。
恐ろしい。革命的だ。2026年、ついに人類はHTTPリクエストを自分で作れるようになったらしい。
サーバーサイドWeb開発では、20年以上前から同じ一言を繰り返してきた。
「クライアントを信用するな」
1. アプリのボタンを消しても、HTTPは消えない
正規アプリが本人の認証トークンを添えて GET /api/orders/12345 を送れるなら、攻撃者も自分の正規トークンで GET /api/orders/12346 を試せる。そこで他人の注文が返ってくるなら、サーバーの認可は何をしていたのだろうか。
他人の注文を返してしまうならIDOR/BOLA、一般ユーザーに管理機能を実行させてしまうならBFLA。OWASPがとうに整理した認可不備だ。
2. 「APIにはアクセス制御を」――大人向けの注意喚起
JPCERT/CCの注意喚起の対策を読めば、目を疑うだろう。
「画面に出ないAPIも含めてアクセス制御を行い、許可された利用者だけを通し、権限を必要最小限にする」（要約）。
そう、APIにはアクセス制御をしましょうと書かれている。
大の大人に「落ちてるお菓子は食べてはいけません」と真剣に説教しているのだ。
そして、同じ文書にある「本来画面操作では実行できない内部APIに対する攻撃」という表現もいただけない。インターネットから到達できるAPIは、外部に開いた入口である。「内部」という呼称も、画面から隠すことも、認可の代わりにはならない。
図書館の貸出本棚に利用者名簿を置き、「業務用」とシールを貼って、「内部マニュアルどおりです」と説明しても、誰も納得しないだろう。
3. APKは金庫か。世界中に配った金庫の鍵
APKは利用者に配布される。攻撃者も利用者として入手し、解析できる。
公開用APIキーを識別子として用いる設計はある。だが、共通の特権キーや秘密鍵をアプリへ埋め込み、本人確認や認可の代わりにするなら話は簡単だ。
世界中に金庫の鍵を郵送して、受取人が鍵の形を調べないことを祈っている。
どうやらアプリ開発者は現在のインターネットを支える偉大なる公開鍵暗号方式+共通鍵暗号化方式、その実装のSSL/TLSは知らないらしい。
難読化で手間は増やせる。サーバー側のアクセス権限は、難読化では生えてこない。
4. フリーパスSQLヘルパーを納品する技術力
CRUD APIの自動生成は便利だ。注文番号を受け取り、注文レコードを返すだけなら一瞬で実装できる。
-- 注文番号だけを信用する実装
SELECT * FROM orders WHERE id = :order_id;
-- 単純な本人所有モデルでの制限例
SELECT * FROM orders
WHERE id = :order_id
AND owner_user_id = :authenticated_user_id;
:authenticated_user_id はサーバーが検証済みの認証情報から確定する値だ。こんな初歩処理も攻撃されたサービスには無かったわけだ。
認可を抜いたAPIは、認可を抜いたAPIは、自由にSELECTできるSQLにHTMLのフォームを着せた ようなものである。
この前提がただしいならモバイルアプリの開発ベンダーは、あまりにも恥知らずである
個別の侵害原因はまだ調査中のものも多い。しかし
本番環境のphpMyAdminを無防備に外部公開したら、誰かが止めるはずだ。
ところが同じ危うさをJSONで包み、/api/ と名付ければ、立派なシステムとして納品できてしまうらしい。
設計者は何を設計し、レビュアーは何を確認したのか。「そのAPI、curlから直接叩いたらどうなるんですか？」と、誰一人声を上げなかったのか。
さらに愕然とするのは発注側だ。利用者の個人情報を預かるシステムを購入しながら、画面が動くことだけで検収を済ませたのか。仮に他社の脆弱性診断も入れてたら回避できたろう。できたよな?
結論：2003年の続編には、美しいログイン画面が付いている
現在判明してる攻撃の大半は、昔から知られた対策で防御できたはずだ。サーバー側で利用者を認証し、データごとの認可を行い、管理機能を保護し、入力を検証し、特権的な共通資格情報を配布アプリに入れない。そして、正規アプリでは作れないリクエストを、テストであえて作る。
A2Bという名前が、この基本を見直すきっかけになるなら歓迎したい。
だが認可不備が確認された案件で、ベンダーが「新しいA2B攻撃に対応できなかった」と語るなら、こう尋ねたい。
HTTPリクエストの改変は、いつから未知の先端技術になったのか。
いま公開される被害の大半は高度なAIで投機的実行を裏読みしてROOT奪取されるようなゼロデイ攻撃か？
否、2003年の脆弱なWebを再発明してしまったのである。
当然裏にはAIを使った効率な攻撃者がいるのはほぼ間違いないだろう。
なぜデジタルは買い切りではなく、投資し続ける必要があるのか漏らした企業様々方のお偉いさんはAIを使って百問一答してほしい。