Skip to content

Docs: add security notes for network-exposed MCP servers #101

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
TheodorNEngoy wants to merge 1 commit into
base: main
Choose a base branch
from
+34 −0
Open

Docs: add security notes for network-exposed MCP servers #101

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,3 +3,7 @@
A repository of servers and clients from the following Model Context Protocol tutorials:
- [Quickstart](https://modelcontextprotocol.io/quickstart) – a simple MCP weather server
- [Building MCP clients](https://modelcontextprotocol.io/tutorials/building-a-client) – an LLM-powered chatbot MCP client

## Security Note

These examples are intentionally minimal. If you expose an MCP server over a network (HTTP/SSE/WebSocket), add authentication and basic hardening (CORS allowlist, request size limits, timeouts, rate limits, and log redaction). See [`SECURITY.md`](./SECURITY.md).
30 changes: 30 additions & 0 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
# Security Notes (Quickstart Resources)

These examples are intentionally minimal and optimized for learning. Before using similar patterns in production, apply basic hardening.

## If You Expose An MCP Server Over A Network (HTTP/SSE/WebSocket)

- **Require authentication**: do not expose unauthenticated tool endpoints to the public internet.
- **Treat browsers as hostile**:
- Do not use wildcard CORS (`Access-Control-Allow-Origin: *`) on authenticated endpoints.
- Do not reflect `Origin` without allowlist validation.
- Prefer an explicit origin allowlist.
- **Bound resource usage**:
- Set an explicit maximum request body size.
- Add timeouts to outbound requests.
- Add rate limits (per user/token and/or per IP).
- **Avoid RCE primitives in tools**:
- Avoid `eval` / dynamic code execution.
- Avoid invoking a shell with attacker-controlled input (`exec`, `sh -c`, `shell=True`).
- If you must run commands, enforce strict allowlists and pass arguments as arrays (no shell).
- **Don't leak secrets**: redact `Authorization`, cookies, and API keys from logs.

## Local-Only Usage

If you run these examples locally via stdio transports, your main risks are still:

- accidentally adding dangerous tools (filesystem/shell) without strict controls
- leaking secrets via logs or environment

When in doubt: keep tool capability narrow and add input validation.