MCP Security Best Practices は「つながる」より先に、誰の権限を誰が横取りできるかを見る
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- remote MCP で先に怖いのは、便利につなぐことではなく、ある client のために取った承認結果や token が別の client や別の server に流れることだ。
- この docs は、その事故を抽象論で済ませず、同意の結び付け、戻り先 URL の確認、token の渡し方、認可先 URL の探索まで、どこを塞ぐべきか具体化している。
- とくに confused deputy、per-client consent、token passthrough、SSRF は、remote MCP を local MCP の延長で入れると見落としやすい論点である。
- つまり remote MCP の本体は transport の便利さではなく、『誰の承認結果を誰が使える構成なのか』を説明できることだ。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
このページは security 一般論ではなく、remote MCP 実装で起きる攻撃の流れをかなり具体的に書いています。confused deputy は、正当な権限を持つ中継役が別 client のためにその権限を悪用される問題です。対策として、client ごとの同意、承認後の戻り先 URL の厳密一致、`state` 検証、token の素通し禁止、metadata discovery で拾う URL の制約まで明示しています。remote MCP は transport より、認可と URL 信頼の設計が本体だと読み替えるべき原典です。
なぜ重要か
日本語圏では MCP を『AI tool 連携の便利な規格』として先に学び、認可は後で詰める流れになりやすいです。しかし remote MCP を業務導入するなら、その順番は危ない。接続成功そのものが攻撃面になるからです。誰が同意したか、どの token がどの server 用か、どの URL を信用してたどったかを説明できない構成は、開発者だけでなく PM や導入責任者にとっても本番運用の土台として弱いままです。
技術的ポイント
- confused deputy は、正当な権限を持つ proxy が別 client に悪用される問題である。third-party API につなぐ MCP proxy で起きやすい。
- per-client consent は client ごとの同意であり、ユーザーがどこかで一度承認しただけでは足りない。どの client_id のための同意かを束縛する必要がある。
- `redirect_uri` 厳密一致と `state` 検証は、認可コード横取りを防ぐ基本防御である。部分一致やワイルドカードは危険である。
- token passthrough は、上流で受けた token を別 server へそのまま流す anti-pattern である。token の宛先境界を壊すため避けるべきだ。
- metadata discovery は認可関連 URL を自動で見つける手順だが、悪意ある URL を拾うと SSRF で内部 IP や `localhost` を踏み台にされうる。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| confused deputy | 権限横取り型の代理人問題 | 正当な権限を持つ中継役が、別 client のために悪用される問題。remote MCP の認可設計で重要になる。 |
| per-client consent | client ごとの同意 | 利用 client ごとに別々の同意を取る考え方。どの client の承認結果かを曖昧にしないために要る。 |
| redirect_uri exact match | `redirect_uri` の厳密一致 | 承認後に戻す先を完全一致で縛ること。少し違う URI を許すと認可コード奪取の入口になる。 |
| state validation | `state` 検証 | 返ってきた OAuth 応答が、自分の開始した要求に対応するか確かめる手順。 |
| token passthrough | トークン素通し | 受け取った token を別先へそのまま渡す危険な設計。token の宛先境界を崩しやすい。 |
| SSRF | サーバー側リクエスト強要 | 攻撃者が server に内部向け URL を踏ませる攻撃。metadata discovery や fetch 設計で対策が要る。 |
試すなら
- remote MCP や proxy を使っている箇所を洗い出し、誰が token を保持し、誰が同意を出し、誰のための承認結果なのかを書き出す。
- 承認後の戻り先 URL で部分一致やワイルドカードを許していないか、`state` 未検証がないかを先に潰す。
- metadata discovery で辿る URL に HTTPS 制約、内部 IP 拒否、loopback 例外条件を置けているか確認する。
注意点
- このページは原則と攻撃類型を示すが、各 OAuth library がどこまで自動で守ってくれるかは別問題である。実装依存の思い込みは危険だ。
- local stdio MCP の成功体験を、そのまま remote MCP へ延長すると判断を誤る。OAuth をまたいだ時点で責任境界が一段増える。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。