Move to remote HTTP safely
Write a threat checklist
Turn the server architecture into a short list of assets, entry points, abuse cases, controls, and remaining risk before deployment.
8 minute lesson
Create SECURITY.md with five headings: Assets, Entry points, Abuse cases, Controls, Remaining risks.
Start with assets. In this project they include note contents, future backend credentials, caller identity, logs, and deployment configuration.
Then list entry points:
- the command a host launches over stdio
- the public HTTP endpoint
- tool arguments and resource URIs
- prompt arguments and returned note text
- dependencies, environment values, and logs
Connect each abuse case to a concrete control:
| Abuse case | Control | Verification |
|---|---|---|
| Oversized search | Schema and result cap | Call with 101 characters and limit 11 |
| Unknown or expanded ID | Exact stable-ID lookup | Call with a missing ID and path-like text |
| Prompt injection in note | Untrusted-content handling | Run the harmless injection test |
| Token for another service | Audience validation | Present a wrong-audience token |
| Secret in logs | Redaction and safe fields | Inspect captured stderr and platform logs |
| Dependency compromise | Pinning and review | Record lockfile and audit process |
Add controls that belong outside the MCP handler too: HTTPS, host and origin validation, rate limits, timeouts, secret storage, and least-privilege backend access.
Do not write “mitigated” without evidence. Use statuses such as implemented, tested, planned, or accepted. Name an owner for every remaining production risk.
The checklist is useful when architecture changes. Revisit it whenever a new tool, data source, credential, transport, or dependency expands the boundary.
Lesson completed