シャドーAPIとは？未管理API・古い接続先URL・Swagger/OpenAPI露出をどう防ぐか

シャドーAPIとは何か

API セキュリティ一般論ではなく台帳不備の問題として見る

シャドーAPIは、SQLインジェクション や 認証不備 のような個別脆弱性名ではありません。近いのはOWASP API Security Top 10 2023 の API9: Improper Inventory Management↗です。OWASP は、古い API バージョンや未修正の接続先URL が残り、資産台帳や廃止計画が不十分だと、攻撃者は旧バージョンや不要に露出した API ホスト から侵入しやすくなると整理しています。

重要なのは、OWASP が単に「古い API は危ない」と言っているのではなく、どの環境で、誰に公開され、どのバージョンが動き、いつ止めるかを説明できない状態を問題の中心にしている点です。つまりシャドーAPIは、開発速度の副作用ではなく、台帳と運用期間管理の失敗です。

未管理API、古い接続先URL、公開ドキュメント は同じ根を持つ

実務でシャドーAPIとして見つかるものは 1 種類ではありません。たとえばモバイルアプリ向けの旧バージョン、ベータ用ホスト、委託先連携専用の経路、停止したはずの webhook 接続先URL、公開された Swagger UI、OpenAPI JSON / YAML、PoC 時に作った検証用 API などです。見た目は別問題ですが、根は同じです。台帳にあるはずの API台帳と、外から実際に見えている API 面が一致していないことです。

そのため、シャドーAPI対策は APIゲートウェイ の有無だけでは片付きません。アタックサーフェスや未管理資産リスクと同じく、外部観点で見える公開面と、内部台帳を付き合わせる発想が必要です。

ここで重要なのは、「危険な API があるか」だけでなく、いま外から見えている API 面を説明できるかを確認することです。利用停止予定の接続先URL、委託先だけが使うはずだったホスト、旧版ドキュメントの残骸は、個別の脆弱性診断だけでは優先度が付きにくく、台帳と公開面の差分として見た方が整理しやすくなります。

検索で「shadow api」「シャドーAPI」を調べる読者の多くは、すでに API 一覧が崩れ始めており、「何が残っているか分からない」状態に近づいています。その段階では、脆弱性の種類を増やして並べるより、誰の API が、どの環境で、どの版で、まだ外に残っているかを先に説明できる状態へ戻す方が、実際の閉鎖判断と是正対応を進めやすくなります。

なぜシャドーAPIは見逃されやすいのか

マイクロサービス、プレビュー環境、委託先連携で ホスト とバージョン が増え続ける

OWASP API9 は、マイクロサービス のような現代的な構成が API ホスト の 不要な露出 を生みやすいと説明しています。これは抽象論ではありません。現場では、機能ごとにサービスが分かれ、プレビュー、テスト、委託先連携、リージョン別に 接続先URL が増え、さらにバージョンも並行します。すると「今動いている本番 API」は把握していても、古いバージョンや別ホストがまだ到達可能かまでは追い切れなくなります。

特に危険なのは、新しい本番 API には WAF、認証、利用回数制限 が入っていても、ベータ環境のホストや旧バージョンには同じ保護が入っていないケースです。OWASP の 事例 1 でも、正式ホストでは利用回数制限されていた パスワード再設定 API が、ベータ版 API ホスト では 利用回数制限 なしで残っていました。シャドーAPIの実害は、こうした保護のつけ忘れた別面で起きます。

Swagger / OpenAPI は探索の近道になりやすい

Swagger UI や OpenAPI 自体が直ちに脆弱性、というわけではありません。ただし公開状態で置かれると、攻撃者にとっては接続先URL 一覧、パラメータ、サーバー情報、バージョン、認証の手がかりをまとめて渡す導線になります。ZAP の OpenAPI 対応↗も、対象範囲内の OpenAPI 定義ファイル を自動検出して巡回 / 取り込み できると説明しています。つまり露出した 定義ファイル は、そのまま探索効率を上げます。

さらに ZAP にはSwagger / OpenAPI パスに露出した秘密情報↗という 検知ルール があり、Swagger UI 接続先URL が クライアントシークレット、APIキー、OAuthトークン などの 機微な秘密情報 を HTMLソース に露出しているケースを高リスクとして扱っています。問題はドキュメントが存在することではなく、ドキュメントの公開範囲と含まれる情報が統制されていないことです。

API台帳と 実行時 観測が別系統で管理されがち

台帳が崩れるもう一つの理由は、設計時 と 実行時 の管理が分断されることです。Microsoft Learn の Azure API Center overview↗は、API台帳を 運用期間 段階 や 配備先 に関係なく 一元管理場所 で追い、unmanaged APIs や APIs under development も含めるべきだと説明しています。逆に言えば、ここを別々に持つと「開発中だから catalog 外」「APIゲートウェイ に載っていないから台帳外」という盲点が生まれます。

同じ資料では、Dev Proxy などと組み合わせて 未登録のシャドーAPI を使わないようにできるとしています。これは、シャドーAPI対策が検知だけでなく、未登録 API を使わせない統制まで含むことを示しています。台帳化と利用制御が分かれると、見つけても減りません。

最初に確認すべき5つのポイント

1. ホスト / バージョン / 環境 が台帳に揃っているか

OWASP API9 の対策項目でも最初に来るのは、すべての API ホストの台帳です。ここで重要なのは 接続先URL 名の一覧だけではなく、本番 / 検証環境 / テスト / 開発 のどこで、誰が ネットワークアクセス を持ち、どのバージョンが動くかを持つことです。ホスト 名だけでは足りません。

たとえば「api.example.com」だけ台帳にあり、「beta-api.example.com」や「/v1/legacy/」が台帳外なら、そこが典型的な ドキュメント起因の見落とし です。まずはDNS棚卸しとサブドメイン監視を通して、外から見えている API 面を洗う方が早いです。

2. OpenAPI 定義ファイル と Swagger UI の公開範囲が妥当か

OWASP API9 は、API documentation は 利用を許可した人だけ にすべきだと明示しています。ここは日本語の実務で誤解されやすいポイントです。Swagger UI を出していること自体が即 NG なのではなく、誰でも読めるパスに置き、定義ファイル と秘密情報を一緒に見せてしまうことが問題です。

特に SaaS や委託先連携で「/swagger」、「/swagger-ui」、「/openapi.json」、「/v3/api-docs」のような経路が残ると、攻撃者はドキュメントを読んで経路全体を把握しやすくなります。公開が必要なら認証と閲覧対象 を限定し、不要なら インターネット から見えない場所へ寄せるべきです。

3. 古い接続先URL に保護強化が反映されているか

OWASP API9 は、新しいバージョンで保護強化 を入れたなら、古いバージョン側に 後方修正 するか、早く停止するかを判断しろと書いています。ここでのリスクは「古い 接続先URL があること」ではなく、古い 接続先URL だけが weaker security requirement のまま外に残ることです。

典型例は、正式版では MFA 前提、厳しい 利用回数制限、厳格な CORS だが、旧バージョンやベータ環境のホスト では未設定のまま、という状態です。閉じる順番は、ドキュメント削除より前に経路停止、DNS / ホスト 停止、利用側の移行確認まで含めて決める必要があります。

4. 委託先連携 / 外部委託先とのデータの流れ が台帳に入っているか

OWASP API9 の 事例 2 は、外部委託先とのデータの流れの台帳がないことを問題にしています。これはシャドーAPIを「自社が出している REST API」の問題に閉じないために重要です。委託先連携 向け API、委託先連携、外部 webhook、ETL 用 API も、誰へどの data を渡しているかが台帳にないなら死角です。

技術的に公開でなくても、業務上の必要性や承認が説明できないデータの流れは危険です。API台帳はパス一覧だけではなく、何を誰に渡す API なのかまで持って初めて使えます。

5.管理責任者と 廃止計画 が固定されているか

ドキュメントが古い理由も、古い接続先URL が残る理由も、多くは管理責任者不在です。Azure API Center の FAQ でも、設計時の統制と実行時の統制を分けて説明していますが、現場ではこの境界で「使っている人はいるが責任者が曖昧」という API が生まれやすくなります。

API ごとに最低限必要なのは、管理責任者、運用段階、バージョン、配備先、閲覧対象、ドキュメントの場所、廃止予定日 です。これがない API は、見つけても閉じられません。

Swagger / OpenAPI の露出はどこまで危険なのか

ドキュメント露出そのものより、探索効率と秘密情報の混入が問題になる

Swagger UI や OpenAPI 定義ファイル が見えるだけで侵害、とは言えません。ですが、攻撃者にとってはどの経路があり、どの パラメータ を受け、どんなバージョンがあり、どのホストを使うかを短時間で集められる材料になります。ZAP の OpenAPI 対応 が 定義ファイル を自動検出して巡回 / 取り込み できるのは、まさにドキュメントが探索効率を高めるからです。

そのうえで最悪なのが秘密情報の混入です。ZAP の 検知ルール 100043-2 は、Swagger UI 接続先URL が クライアントシークレット、APIキー、OAuthトークン を HTMLソース に露出しているケースを高リスクとしています。つまり「社内向けドキュメントのつもり」が公開パスに残ると、単なる情報整理ページでは済みません。

公開ドキュメント を許すなら 閲覧対象 と内容 を限定する

もしドキュメントを公開する必要があるなら、やるべきことは単純です。公開閲覧対象 を定義し、定義ファイル に含める server、example、秘密情報、社内向けパス を制御することです。OWASP API9 が「documentation available only to those authorized to use the API」とするのは、このためです。

実務では、公開開発者向けポータル と 社内運用向けドキュメント を分ける方が安全です。委託先連携 専用ドキュメント、社内管理用APIドキュメント、検証環境 用 定義ファイル を同じ経路に置くと、最終的に誰に見せる想定か分からないドキュメントになります。

さらに重要なのは、ドキュメントを閉じたあともその URL とホスト名が探索対象として残りやすいことです。Swagger UI や OpenAPI 定義ファイルを一度公開した環境では、利用者向け案内、委託先向け手順書、古い接続設定に URL が残り続けることがあります。したがって、ドキュメントの公開停止は単なる 404 化ではなく、台帳、導線、案内文、利用者への移行連絡まで含めて完了条件を定義する必要があります。

すぐできる対策

1.外部観点の ホスト台帳と 内部台帳 を突き合わせる

最初にやるべきは、APIゲートウェイ設定だけを見ることではありません。インターネットから見える API ホスト、サブドメイン、公開ドキュメント用パス を洗い、内部台帳と差分を取ることです。ここで「本番ではないから」「委託先連携用だから」は免罪符になりません。OWASP API9 でも、環境とアクセス範囲が説明できないホストは死角 とされます。

2. ドキュメント用パス と 定義ファイル を認証付きに寄せる

「/swagger」、「/swagger-ui」、「/openapi.json」、「/v3/api-docs」のようなパスは、公開が不要なら インターネット から外してください。公開が必要なら、認証、閲覧対象 制御、秘密情報の除去、サンプルデータの見直しを入れます。ドキュメントを配備のたびに自動生成するなら、そのビルド工程 側で公開可否と内容ポリシーを固定した方が安定します。

3. 廃止予定バージョン の停止計画 を課題化する

古いバージョンは「いつか止める」では閉じません。API台帳に 廃止予定 / プレビュー / 本番 を持たせ、廃止予定日、利用側移行状況、後方修正の要否を課題一覧にして初めて減ります。残すなら本番相当の保護水準を与え、残せないなら利用側の移行とセットで止めるべきです。

4.管理責任者、閲覧対象、データの流れ を 属性情報 で必須化する

Azure API Center が built-in / custom 属性情報 で統制をかけるように、台帳 側にも最低限の必須項目 を作るべきです。管理責任者、環境、閲覧対象、定義ファイルの場所、配備先、廃止計画、データ機密性 が空の API は、登録未完了として扱った方がよいです。

5. 月次見直しで「新規」「旧バージョン」「公開ドキュメント」を固定観測する

シャドーAPIは単発の棚卸しで終わりません。毎月見る固定項目として、「新規 ホスト / バージョン」「廃止予定なのに生存」「公開ドキュメント」「管理責任者未設定」「委託先連携のデータフロー変更」を持つと再発を減らせます。見つけた件数より、台帳と実態の差分がどれだけ減ったかを見る方が実務的です。

この月次見直しでは、閉じたはずの URL が本当に閉じているかと新しく増えたドキュメントが承認済みかを毎回確認することが重要です。API は機能追加のたびに増えやすく、放置されたプレビュー環境や旧バージョンは少しずつ増殖します。月次レビューを固定すると、台帳更新と公開面確認を同じ会議で回しやすくなります。

シャドーAPI対策ならASM診断 PRO

ASM診断 PRO は、API の通信記録や内部 API 台帳の代替製品ではありません。つまり、OpenAPI 定義ファイル の検査やバージョン統制を内部で完結させるツールではない、という意味です。ただし、外から見える API ホスト、古いサブドメイン、放置された公開ドキュメント用URL の現状確認を始める入口としては相性が良いです。

シャドーAPI問題は、内部台帳だけでは完結しません。実際に インターネット からどのホストが見え、どのパスが応答し、どのサブドメインが残っているかを外部観点で見ないと、台帳の漏れに気づきにくいからです。まず 公開診断で外から見える面を洗い、その後に外部公開資産台帳や内部 API 台帳へ戻すと、誰の API をどこから閉じるべきかを整理しやすくなります。

特に、ベータ環境のホスト、委託先連携 用サブドメイン、古いリージョン別ホスト、停止済みのはずのドキュメント用接続先URL などは、DNS や HTTP 応答の形で外に残りやすい領域です。サブドメイン棚卸し、DNS棚卸し、管理画面・検証環境露出と合わせて見ると、シャドーAPIを API だけの話に閉じず、公開面全体の運用問題として扱いやすくなります。とくに「閉じたつもりの旧ホスト」を洗う入口として有効です。

よくある質問（FAQ）

シャドーAPIは APIゲートウェイ を入れれば解決しますか

それだけでは不十分です。APIゲートウェイ 配下の本番 API は見えても、古いホスト、ベータ環境の接続先URL、委託先連携の経路、公開ドキュメント、台帳外のデータフローが残れば死角は消えません。設計時台帳と外部観点の現状確認の両方が必要です。

Swagger UI が公開状態だと必ず危険ですか

必ずではありません。ただし公開ドキュメントは 接続先URL の発見を強く助けますし、秘密情報や社内サーバー情報が混ざると危険度が一気に上がります。少なくとも 閲覧対象 を定義し、不要なドキュメントは認証付きへ寄せる方が安全です。

古い接続先URL はすぐ止めるべきですか

利用側移行 を無視して即停止すると業務影響が出るため、廃止計画 が必要です。ただし新しいバージョンに保護強化が入っているなら、旧バージョンを放置しない判断は急ぐべきです。後方修正 か停止 かを明示してください。

社内API台帳 があれば外部観点の確認は不要ですか

不要にはなりません。台帳は正本ですが、公開面の実態を保証しません。DNS、サブドメイン、ドキュメント用パス、廃止予定ホスト が インターネット からどう見えているかは別確認が必要です。シャドーAPIはこの差分で見つかることが多いためです。

最初の 1 か月で何を完了条件にすればよいですか

まずは ホスト / バージョン / ドキュメント の一覧、管理責任者、環境、公開 / 社内 / 委託先連携 区分、廃止候補まで揃えば十分です。完璧な台帳より、閉じるべき古い接続先URL と公開ドキュメントが分かる状態を先に作る方が効果が出ます。

まとめ

シャドーAPIは、新しい API が増えること自体の問題ではありません。危険なのは、ホスト、バージョン、ドキュメント、データの流れ が台帳外で動き、誰がどこまで公開しているか説明できない状態です。特に 古い接続先URL、ベータ環境のホスト、公開ドキュメント、委託先連携 は、本番本体より先に死角になりやすい領域です。

• API台帳は ホスト、バージョン、環境、閲覧対象、管理責任者まで持つ
• Swagger / OpenAPI は公開パスへ置きっぱなしにしない
• 廃止予定バージョンは 後方修正 か停止 を決める
• 外部観点の公開面確認を月次見直しに固定する

まずは外から見える API ホスト とドキュメント用接続先URL を確認し、その差分を内部台帳へ戻してください。そこから外部公開資産台帳とサブドメイン監視へつなぐと、シャドーAPIを単発の棚卸しで終わらせずに運用へ載せやすくなります。

直し始める順番も明確です。まずホストとバージョンの差分を洗い、次に公開ドキュメントの扱いを整理し、最後に廃止計画と管理責任者を固定します。シャドーAPIは脆弱性診断だけで消える問題ではなく、台帳と現実を毎月突き合わせる運用課題です。ここを定着させると、古い接続先 URL や放置されたドキュメントが再び増えにくくなります。

実務では、台帳が正しいことより台帳と外部から見える実態の差分を早く見つけることが重要です。シャドーAPIを減らすとは、API の件数を減らすことではなく、誰の API がどこで動き、いつ止めるかを説明できる状態へ戻すことです。