スマートフォンアプリにログイン画面があり、管理メニューも見えない。それでも、サーバー側の確認が不足していれば、情報が取り出される危険は残ります。利用者が触る画面と、実際の処理を行うサーバーは、分けて考える必要があります。
NICTは2026年10月13日、アプリの解析を起点としたバックエンドサーバーへの攻撃について注意喚起を公表しました。この記事では攻撃の再現方法ではなく、アプリやWebサービスを運営・発注する側が、どこを確認すべきかを整理します。NICTの注意喚起
アプリの裏側には、処理を受け付ける入口がある
たとえば会員情報を表示するアプリでは、画面の操作に応じてサーバーへ要求を送り、必要なデータを受け取ります。この受け渡しに使われる入口がAPIです。スマートフォンだけの話ではなく、ブラウザーで使うWebアプリにも同じ考え方があります。
アプリに組み込んだ通信先や処理の手掛かりは、利用者の端末へ渡ります。「URLを宣伝していない」「ボタンを隠している」ことを、保護の根拠にはできません。APIの場所を知られる可能性を前提に、サーバーが要求を確かめる設計が必要です。
ログインできることと、何をしてよいかは別
本人であることを確かめる認証と、その人がどの情報を扱えるかを決める認可は、役割が異なります。ログイン済みという理由だけで、すべての利用者の情報を読めてよいわけではありません。
会員Aが自分の申込履歴を見る場合、サーバーは、その履歴がAに属することも確かめる必要があります。画面が正しい番号を送ることに頼らず、要求に含まれる番号と本人の権限を照合します。確認は表示だけでなく、更新・削除・ファイル取得にも必要です。
ここは発注者にも質問できます。「ログインしていれば使えますか」だけでなく、「他の会員のデータを指定した場合、サーバー側で拒否しますか」と聞くと、確認したい境界が明確になります。
画面の入力制限だけでは、APIの制限にならない
画面に文字数制限があっても、サーバー側で同じ確認をしているとは限りません。受け付ける型、長さ、ファイルサイズ、処理回数、同時に動かす量なども、入口で確認する対象です。
特に外部サービスへ処理を依頼するAPIは、要求を受けるたびに費用が生じる場合があります。データ漏えいだけでなく、処理の集中や予想外の請求も運用上の問題です。OWASPのAPI Security Top 10でも、資源の消費を制限しない設計が挙げられています。OWASP：資源消費に関するリスク
公開問い合わせのようにログインを求めない機能もあります。その場合も「公開だから何でも受ける」ではなく、必要な入力と処理だけを受け付けるようにします。
運営側が確認したいこと
- APIの一覧、用途、管理担当者は把握されていますか。
- 認証だけでなく、データや操作ごとの権限をサーバーで確認していますか。
- 入力の大きさや回数、同時処理、外部サービスの費用を制限していますか。
- 不要になった旧APIやテスト用の入口が残っていませんか。
- 異常が起きた場合、記録を確認し、対象機能を止める方法がありますか。
この質問だけで安全性を判定できるわけではありません。ただ、アプリの見た目や機能一覧では分からない運用条件を、制作会社や保守担当と話すきっかけになります。管理者専用、一般会員向け、ログイン不要といった入口の区別も併せて整理します。
確認のために、本番を無断で試さない
自社サービスであっても、外部の基盤や委託先が関わる場合があります。権限確認や負荷の試験は、対象・方法・期間を合意し、テスト用データと隔離した環境で進めるのが基本です。顧客情報を使って、他人の情報へアクセスできるか試すような確認は避けます。
また、管理画面の非表示や難読化を直しただけで、すべての問題が解決するとは限りません。サーバー側で何を受け付け、何を拒否するかを確かめ、必要なら専門家に検証を依頼します。
次の改修では、画面とAPIを一緒に確認する
レイヤーワークスでは、Webアプリの機能を考える際、操作しやすい画面と同時に、裏側の入力・権限・処理の境界も確認することを重視します。画面が完成した段階で、APIの管理責任や異常時の連絡先が決まっていなければ、運用の準備はまだ途中です。
まずは既存の機能を一つ選び、「誰が、どの情報を、どの操作で扱うのか」を書き出してみてください。画面では分からなかった確認事項が、具体的な質問になります。
