MCP transports は「つながる」より先に origin と localhost を守れと言っている
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- MCP の接続方式を HTTP に広げるなら、便利さの前に「誰がその口に入れるか」を絞らないと、ローカルの道具箱がそのまま外から叩かれる。
- この spec の重要点は、transport を `stdio` と `Streamable HTTP` に分けたこと自体より、HTTP で公開するなら何を最低限守るべきかを明文化した点にある。
- `Streamable HTTP` は旧 `HTTP+SSE` transport を置き換えるが、同時に `Origin` header 検証、`127.0.0.1` bind、認証の実装を security warning として要求している。
- 日本の開発者がここから学ぶべきなのは、MCP server を localhost で動かしているだけでは安全とは言えず、transport 層にも明示的な防御が要るということだ。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
この spec は transport を大きく二つに整理しています。`stdio` は同一マシン上の process 間通信を前提にし、server を subprocess として起動して標準入出力でやり取りする形です。もう一方の `Streamable HTTP` は、独立した server process が複数 client connection を扱え、HTTP POST / GET を使い、必要に応じて SSE で複数メッセージを流せる形です。 ただし本当に重要なのは、`Streamable HTTP` の security warning です。spec は `Origin` header を検証して DNS rebinding を防ぐこと、local 実行時は `0.0.0.0` ではなく `127.0.0.1` に bind すること、すべての接続に proper authentication を実装することを明記しています。つまり HTTP transport は「使える」だけでは実装不足です。
なぜ重要か
日本語圏では MCP が server 一覧や接続デモの話で消費されやすく、transport 層の安全線まで話が降りてこないことが多いです。ですが remote MCP を本番で使うなら、危険は tool schema より前、接続口そのものにあります。この spec はその基本線を与えます。 また、local tool を browser や desktop app から呼ぶ設計では、開発者が「ローカルだから安全」と思い込みやすい。DNS rebinding のような経路はその思い込みを壊します。MCP の security を語るなら authorization だけでなく transport も同時に見ろ、というのがこのページの実務価値です。
技術的ポイント
- `stdio` transport は local process 間通信向きで、subprocess の標準入出力を使って MCP message をやり取りする。
- `Streamable HTTP` transport は 2024-11-05 版の `HTTP+SSE` transport を置き換える仕様で、HTTP POST / GET と optional SSE に対応する。
- spec は `Streamable HTTP` 実装時の security warning として、`Origin` header 検証、`127.0.0.1` bind、proper authentication を挙げている。
- `Origin` 検証は browser 由来の remote website から local MCP server へ不正に届く DNS rebinding 攻撃を防ぐための線であり、単なる CORS 設定の装飾ではない。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| stdio | 標準入出力 transport | 同一マシン上の process 間で使う近い接続方式。HTTP を開かずに済むぶん attack surface を狭めやすい。 |
| Streamable HTTP | ストリーミング対応HTTP transport | HTTP POST / GET と optional SSE を使う transport。便利さと引き換えに Origin、認証、bind 先の防御が要る。 |
| Origin header | Origin ヘッダー | 接続元 web page の出所を示す情報。local MCP server を browser 経由で悪用されないための検証点になる。 |
| DNS rebinding | DNS リバインディング | remote website が local server へ届くように見せかける攻撃。localhost だから安全という思い込みを壊す。 |
| authentication | ||
| localhost |
試すなら
- まず自分の MCP server が `stdio` で足りるのか、HTTP が本当に必要なのかを切り分ける。
- HTTP が必要なら、`0.0.0.0` bind を避け、`Origin` 検証と認証が実装済みかを最初に確認する。
- local 開発でも「browser から開けたら便利」を優先せず、どの client だけが接続できるべきかを書き出す。
- spec version 差分を追い、旧 `HTTP+SSE` 前提の実装や解説が残っていないかを見直す。
注意点
- この spec は transport 層の最低線を示すが、tool ごとの認可や downstream system の権限制御までは代わりにやってくれない。
- `localhost` bind だけでは十分ではない。browser 経由の到達や認証欠如があれば依然として危ない。
- 旧 transport の説明記事や実装サンプルをそのまま読むと、現行 spec と安全要件がずれている可能性がある。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。