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

シャドーAPIとは何か

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

シャドーAPIは、SQL injection や broken auth のような個別脆弱性名ではありません。近いのはOWASP API Security Top 10 2023 の API9: Improper Inventory Management↗です。OWASP は、古い API version や unpatched 接続先URL が残り、assets台帳や retirement strategy が不十分だと、攻撃者は旧 version や不要に露出した API ホスト から侵入しやすくなると整理しています。

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

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

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

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

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

マイクロサービス、preview、委託先連携 連携で ホスト と version が増え続ける

OWASP API9 は、modern concepts like マイクロサービス が API ホスト の 不要な露出 を生みやすいと説明しています。これは抽象論ではありません。現場では、機能ごとに service が分かれ、preview、test、委託先連携、region 別に 接続先URL が増え、さらに version も並行します。すると「今動いている本番 API」は把握していても、古い version や別 ホスト がまだ 到達可能 かまでは追い切れなくなります。

特に危険なのは、新しい production API には WAF、auth、利用回数制限 が入っていても、beta ホスト や旧 version には同じ保護が入っていないケースです。OWASP の Scenario #1 でも、正式 ホスト では 利用回数制限 されていた reset password API が、beta API ホスト では 利用回数制限 なしで残っていました。シャドーAPIの実害は、こうした保護のつけ忘れた別面で起きます。

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

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

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

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

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

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

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

1. ホスト / version / 環境 が台帳に揃っているか

OWASP API9 の prevention でも最初に来るのは、all API hosts の台帳です。ここで重要なのは 接続先URL 名の一覧だけではなく、production / staging / test / development のどこで、誰が ネットワークアクセス を持ち、どの version が動くかを持つことです。ホスト 名だけでは足りません。

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

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

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

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

3. 古い接続先URL に security improvement が反映されているか

OWASP API9 は、新 version で security improvement を入れたなら、old version 側に 後方修正 するか、早く retire するかを判断しろと書いています。ここでのリスクは「古い 接続先URL があること」ではなく、古い 接続先URL だけが weaker security requirement のまま外に残ることです。

典型例は、正式版では MFA 前提、厳しい 利用回数制限、strict CORS だが、旧 version や beta ホスト では未設定のまま、という状態です。閉じる順番は、ドキュメント削除より前に route 停止、DNS / ホスト 停止、client 移行確認まで含めて決める必要があります。

4. 委託先連携 / third-party data flow が台帳に入っているか

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

技術的に public でなくても、business justification や approval が説明できない data flow は危険です。API台帳は path 一覧だけではなく、何を誰に渡す API なのかまで持って初めて使えます。

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

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

API ごとに最低限必要なのは、管理責任者、運用期間 段階、version、deployment、閲覧対象、docs location、廃止予定日 です。これがない API は、見つけても閉じられません。

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

docs 露出そのものより、探索効率と secret 混入が問題になる

Swagger UI や OpenAPI 定義ファイル が見えるだけで侵害、とは言えません。ですが、攻撃者にとってはどの route があり、どの パラメータ を受け、どんな version があり、どの ホスト を使うかを短時間で集められる材料になります。ZAP の OpenAPI Support が 定義ファイル を自動検出して spider / import できるのは、まさに docs が探索効率を高めるからです。

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

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

もし docs を公開する必要があるなら、やるべきことは単純です。公開 閲覧対象 を定義し、定義ファイル に含める server、example、secret、internal path を制御することです。OWASP API9 が「documentation available only to those authorized to use the API」とするのは、このためです。

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

すぐできる対策

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

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

2. docs path と 定義ファイル file を auth つきに寄せる

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

3. deprecated version の retirement を backlog 化する

old version は「いつか止める」では閉じません。API台帳に deprecated / preview / production を持たせ、廃止予定日、利用側移行 状況、後方修正 要否を backlog にして初めて減ります。残すなら production 相当の security treatment を与え、残せないなら client 移行とセットで止めるべきです。

4.管理責任者、閲覧対象、data flow を 属性情報 で必須化する

Azure API Center が built-in / custom 属性情報 で governance をかけるように、台帳 側にも最低限の required field を作るべきです。管理責任者、環境、閲覧対象、定義ファイル location、deployment、廃止計画、data sensitivity が空の API は、登録 incomplete として扱った方がよいです。

5. monthly見直しで「新規」「旧 version」「公開ドキュメント」を固定観測する

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

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

ASM診断 PRO は、API request telemetry や internal API catalog の代替製品ではありません。つまり、OpenAPI 定義ファイル の linting や version governance を内部で完結させるツールではない、という意味です。ただし、外から見える API ホスト、古い subdomain、放置された公開ドキュメント用URL の現状確認を始める入口としては相性が良いです。

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

特に、beta ホスト、委託先連携 用 subdomain、古い region 別 ホスト、停止済みのはずの docs 接続先URL などは、DNS や HTTP 応答の形で外に残りやすい領域です。サブドメイン棚卸し、DNS棚卸し、管理画面・staging 露出と合わせて見ると、シャドーAPIを API だけの話に閉じず、公開面全体の運用問題として扱いやすくなります。

よくある質問（FAQ）

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

それだけでは不十分です。APIゲートウェイ 配下の production API は見えても、old ホスト、beta 接続先URL、委託先連携 route、公開ドキュメント、台帳 外の data flow が残れば blindspot は消えません。設計時台帳と外部観点の現状確認の両方が必要です。

Swagger UI が public だと必ず危険ですか

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

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

利用側移行 を無視して即停止すると業務影響が出るため、廃止計画 が必要です。ただし newer version に security improvement が入っているなら、旧 version を放置しない判断は急ぐべきです。後方修正 か retire かを明示してください。

internal API catalog があれば外部観点の確認は不要ですか

不要にはなりません。catalog は正本ですが、公開面の reality を保証しません。DNS、subdomain、docs path、deprecated ホスト が インターネット からどう見えているかは別確認が必要です。シャドーAPIはこの差分で見つかることが多いためです。

最初の 1 か月で何を done にすればよいですか

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

まとめ

シャドーAPIは、新しい API が増えること自体の問題ではありません。危険なのは、ホスト、version、docs、data flow が台帳外で動き、誰がどこまで公開しているか説明できない状態です。特に 古い接続先URL、beta ホスト、公開ドキュメント、委託先連携 連携は、production 本体より先に blindspot になりやすい領域です。

• API台帳は ホスト、version、環境、閲覧対象、管理責任者まで持つ
• Swagger / OpenAPI は public path へ置きっぱなしにしない
• deprecated version は 後方修正 か retire を決める
• 外部観点の公開面確認を monthly見直しに固定する

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