APIセキュリティ対策|管理用APIの悪用と情報漏洩を防ぐ
監修:JIISセキュリティラボ監修者情報を見る
公開:2026年10月15日|最終更新:2026年10月15日
定義
APIセキュリティ対策とは、Webサイトやスマートフォンアプリの裏側で動くAPI(アプリケーション同士の通信の窓口)を通じた不正アクセス・情報漏洩を防ぐ取り組みです。画面からは見えないため対策が後回しになりやすく、2026年に相次いだ国内の漏えい事案では、公開アプリの解析から割り出した管理用APIの悪用が主要な手口のひとつとして注意喚起されています。
仕組み
JPCERT/CC の注意喚起「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」(JPCERT-AT-2026-0030・2026年10月8日公開・10月9日更新)は、2026年9月ごろから相次ぐ個人情報の漏えいを受けて、増えている可能性のある攻撃類型を挙げています。その中の「APIの悪用」では、公開されているスマートフォンアプリを解析してAPIの窓口(エンドポイント)とキーを割り出し、画面操作では呼び出せない内部APIに対して、ユーザー権限の変更や不正なアカウントの作成を試みる、ヘッダーやトークンを操作して応答の違いを探る、NoSQLインジェクションでアカウント情報を少しずつ列挙する、他のシステムから盗んだAPIキーを再利用する、といった手口が示されています。
こうした悪用が成立するのは、APIが「画面から呼ばれる前提」で作られているからです。画面側でボタンを隠しても、APIは直接リクエストできます。窓口ごとに認可(この利用者にこの操作を許すか)を確かめていない、他人のIDを指定しても情報が返るアクセス制御の不備、必要以上の項目を返す応答、回数制限のない呼び出し、有効期限のないトークン、仕様にない入力を受け付ける実装——いずれも通信の形は“正常”なので、既知の攻撃パターンを見る汎用ルールだけでは気づきにくいのが特徴です。
実被害の傾向
会員情報の一括取得(IDを順に変えて列挙する)、権限の書き換えによる管理機能の操作、他人のアカウントの操作、不正アカウントの作成が典型です。注意喚起では、BIツールや社内向けの管理システムなど「一般公開を想定していない」システムが侵入を受けた例も挙げられており、Webサイト本体だけでなく、同じサーバや同じ認証基盤につながるAPIが入口になります。リクエストが正常に見えるため、ログを見ても気づきにくく、外部からの連絡で判明する事案が少なくありません。
対策
- すべての窓口で認可を確かめる:非公開のつもりのAPIも含め、エンドポイントごとに「誰に・どのHTTPメソッドを許すか」を実装する。画面で隠すことは対策にならない。
- 最小権限と、トークンの有効期限・失効:APIの利用者とトークンには必要最小限の権限だけを与え、期限を設け、使われていない・漏れた可能性のあるトークンをすぐ無効にできるようにする。
- 回数制限(レート制限):単位時間あたりのリクエスト数を制限し、ログイン・パスワードリセット・SMS送信・検索などリスクの高い機能には個別の上限を設ける。
- 返す項目を最小限に・IDを推測不能に:応答に不要な個人情報を含めない。連番IDは列挙の足がかりになる。
- 仕様外のリクエストを拒否する:APIの仕様(OpenAPI 等のスキーマ)を定め、定義にない経路・形式・値を受け付けない。
- 不要な窓口を外に出さない:使っていないエンドポイント・管理機能・管理用ポートはインターネットに公開しない。利用地域が限られるなら地域で制限する。
- ログと初動:認証ログ・APIのアクセスログを残し、連続失敗や異常な取得量に気づける仕組みと、被害が疑われるときの初動手順(記録・隔離・連絡・復旧)を備える。保持期限を過ぎたデータは削除する。
いま自分のサイトがどうなっているかは、Webサイトの脆弱性の確認方法の手順で確認できます。
サイトドックでの扱い
サイトドックのプロ(Webアプリ・APIサーバ向け)は、所有者確認と同意のうえでログイン後の画面とAPIまで月次の能動診断の対象に含め、アクセス制御の不備・情報の露出・既知の脆弱性を毎月確認します。エッジでは、API保護(OpenAPI 3.0 のスキーマを登録し、仕様外のリクエストを操作単位で拒否)、アプリ通信の保護(正規のアプリからの通信をヘッダーのトークンまたは利用者単位の署名トークンで識別し、レート制限の過検知を避ける)、レート制限、管理画面パスの制限、サーバの全ポートの外部非公開(Cloudflare Tunnel)を、DNS切り替えとサーバ側の設定で提供します。
エッジで行えるのは「仕様外・過剰・不要な通信を手前で止める」ことまでです。窓口ごとの認可ロジック、トークンの有効期限や失効の設計、返却項目の見直しはアプリ本体の実装に当たるため、診断結果で正直に明示し、開発者の実装まで専門家が伴走します。
対策の実施と運用まで任せる場合の仕組み・料金はサイトドックのご案内をご覧ください。
よくある質問
画面に出していないAPIにも、対策は必要ですか?
APIキーをスマートフォンアプリに埋め込んでいます。問題はありますか?
WAFを入れていれば、APIの悪用は防げますか?
自社のAPIサーバが対象になるか、どう判断すればよいですか?
このページの要点
- 公開アプリの解析から割り出した管理用APIの悪用が、2026年の漏えい事案で主要な手口として注意喚起されている
- 画面で隠してもAPIは直接呼べる。窓口ごとの認可・最小権限・トークンの期限と失効が土台
- レート制限・返却項目の最小化・仕様外リクエストの拒否・不要な窓口の非公開で、正常な形の悪用を減らす
- エッジで止められるのは仕様外・過剰・不要な通信まで。認可ロジックの修正はアプリ側の対策
対策の実施と運用まで、まとめて任せるなら
サイトドックは、月次の定期診断で弱点を継続的に見つけ、エッジで治せるものは速やかに修復する統合型セキュリティサービスです。実施した対策は毎月のレポート(PDF)でお届けします。