画面を隠すだけでは守れない。アプリの裏側も確認すべき理由

画面では操作できないのに、なぜ確認が必要？

会員向けのアプリや業務ツールを作るとき、担当者が最初に確認しやすいのは画面です。ログインすると一覧が出る、編集を押すと入力欄が開く、保存すると内容が変わる。この流れが整うと完成したように見えます。しかし、画面が正しく動くことと、情報の受け渡しが適切に守られていることは、別々に確かめる必要があります。

多くのアプリでは、スマートフォンやブラウザの画面とは別の場所に、情報を保存し、操作を受け付けるサーバがあります。バックエンドとは、この裏側の処理を受け持つ仕組みです。画面は操作の窓口で、サーバが情報を返したり変更したりします。見えている窓口だけを調べても、その後ろでどのように判断しているかまでは分かりません。

例えば、一般利用者には編集ボタンを表示しない設計にしたとします。これは操作の案内としては必要でも、編集する権限があるかどうかを画面だけで判断してよい、という意味ではありません。利用者が送った操作の依頼を受け取る側でも、誰が何をしてよいかを確認する必要があります。

AIを使って画面を作った場合も、制作会社に依頼した場合も、この確認は同じです。作り方だけで安全性は決まりません。見た目が整っているから大丈夫とも、AIで作ったから危険とも言い切れません。どの情報を扱い、どこで権限を判定し、何を確認したかで状態を判断することが大切です。

NICTの発表は「接続先」への注意喚起

NICTは2026年10月13日、公開Androidアプリの解析情報を悪用して接続先サーバを攻撃する手法について、注意喚起を公表しました。名称はA2B攻撃です。これは同機構が情報漏洩の原因の一つとして示したもので、すべての漏洩事案の原因を説明するものではありません。

発表は、Androidアプリを手掛かりにする手法を対象にしています。NICTはiOSやWebサービスでも同様の問題が起きる可能性に触れていますが、あらゆるアプリで同じ被害が確認されたという意味ではありません。本記事でも、確認された対象と、今後注意する可能性を分けて扱います。

このニュースから持ち帰りたいのは、接続先や仕組みが外から分からないという理由だけで、情報が守られると考えないことです。一般に公開するアプリは利用者の端末へ届きます。そのため、内部の情報を完全に隠せるという期待に頼るより、接続先で不適切な依頼を受け付けない設計と確認が必要になります。

なお、ニュースを自社に当てはめるときには、アプリの有無だけで判断しないでください。制作会社へ接続先の管理者を尋ね、保管する情報と権限の設計が分かる資料を確認します。細かい技術資料を経営者がすべて読む必要はありませんが、どこを誰が調べ、何が未確認かを把握できる状態にしましょう。

権限と秘密情報を、画面の外でも確認する

APIは、画面とサーバなどが情報をやり取りするための窓口です。利用者情報を受け取る、予約を登録する、注文を更新するなど、画面操作の裏側で使われます。OWASPのREST Security Cheat Sheetでは、保護が必要なAPIごとにアクセス制御を行うことを示しています。アクセス制御とは、許された相手に、許された操作だけを認める仕組みです。

確認では、「ログインしているか」と「この情報を扱ってよいか」を分けます。利用者本人の予約を見てよいことと、別の利用者の予約まで見てよいことは違います。また、同じ会社の社員でも、閲覧だけ認める人と、情報の変更まで認める人では役割が異なります。ここを整理せず、ログイン済みという理由だけで広い操作を許していないかを見ます。

次に、秘密情報の置き場所を確認します。外部サービスを利用するための鍵や管理者向けの認証情報は、必要な相手だけに扱わせるものです。アプリや公開する画面側へ入れてよい識別情報と、外へ出してはいけない秘密を区別してください。名前にキーと付いているだけで一律に判断せず、用途と権限、提供元の仕様を確かめます。

権限の確認は、開発担当者の記憶だけに頼らず、役割と操作の対応表にすると話が具体的になります。一般利用者は本人情報を閲覧、運用担当者は必要な範囲を更新、管理者はアカウントを管理する、といった整理です。これは一般的な検討例です。自社の契約や業務に合わせて定め、不要な操作は許可しない方針を確認します。

また、退会や契約終了の後に、利用を続けられないかも確認対象です。公開時点で適切でも、人の異動や権限変更で状態は変わります。アカウントを止める担当、必要に応じて秘密情報を更新する担当、管理者権限を見直す時期まで含めると、設計と日々の運用がつながります。

• 利用者ごと：本人以外の情報を扱えない設計になっているか。
• 操作ごと：閲覧・変更・管理の権限をサーバ側でも判断しているか。
• 秘密情報：保管先、利用範囲、失効や更新を担当する人が明確か。

公開前の確認範囲を決め、公開後も追いかける

実際に確認するときは、対象のシステム、アカウント、許可する操作、触れてはいけない本番データを事前に決めます。顧客の個人情報を使って試すのではなく、承認された環境とテスト用データを用意してください。調査は自社が管理権限を持つ範囲で行い、第三者のサービスに対して勝手に確認を進めないことが前提です。

発注者が依頼する際には、「セキュリティも見てください」だけでは範囲が曖昧になります。公開画面の操作、ログイン後の表示、APIの権限、サーバ設定など、どの部分を対象にするかを分けて尋ねましょう。確認できなかった部分も成果物に記載してもらうと、追加で何を依頼すべきかが分かります。

報告では、指摘の数だけを見る必要はありません。どの役割で、どの機能を、どんな条件で確認したのか、結果を確かめるための情報があるかを見てください。問題を直した後にも同じ条件で再確認します。未確認の対象を残したまま、「指摘がないので問題なし」と受け取らないことが大切です。

公開前の仕様や動作を整理する入口として、Custosの公開前診断を利用できます。ただし、画面の確認だけで全APIやサーバ構成の安全性を証明できるわけではありません。必要なセキュリティ診断の対象は個別に確認し、今回公表された攻撃をサービスだけで防げるとは考えないでください。 このサービスの対象はWebアプリで、ネイティブのAndroid・iOSアプリは対象外です。画面・機能・仕様とのズレを確認するサービスとして利用し、詳しい安全性の確認は別途の脆弱性診断へつなげます。

公開後は、アプリ側の変更がなくても、接続先や外部サービスが更新されます。公開Webサイトの確認にはCustosのURL診断も入口になりますが、内部APIや権限設定まで含むかは別に確かめます。継続診断、内部の点検、異常時の連絡先を組み合わせ、見ている範囲を明確にして運用しましょう。

まとめ：見た目と、情報を渡す判断を両方見る

画面を隠すことは、必要な人へ操作を案内するために役立ちます。一方で、情報を渡してよいか、変更を認めてよいかは、サーバ側でも確認する必要があります。アプリの見た目と裏側の処理を分けて考えると、公開前に誰へ何を依頼するかが明確になります。

NICTの注意喚起は、仕組みを知られないことへの期待だけに頼らず、接続先を含めて点検するきっかけです。公開前は動作と確認範囲を整理し、公開後は脆弱性診断と運用の見直しを続けましょう。確認の結果と限界を記録し、変更に合わせて確かめ直すことが、継続してサービスを提供する土台になります。