Securing an MCP server that exposes internal data: a complete answer

Securing an MCP server that exposes internal data: a complete answer

This is the interview question, and the whole module is the answer. Put it in this order.

1. Decide whether it needs network exposure at all. A local stdio server for one user needs no OAuth; treat the launch command as code you run.
2. Authenticate every request (HTTPS only; Authorization: Bearer; never a token in the URL). Verify signature, issuer, expiry and audience; the audience is this server. Return 401 with a challenge, 403 for scope.
3. Publish Protected Resource Metadata and use an authorization server you did not write. Require PKCE (S256) and exact redirect matching; use Client ID Metadata Documents or pre-registration, not open registration with a shared consent cookie.
4. Scope by capability, minimal first. Challenge for what the call needs. Check scope before the tool runs, then check the record: the caller comes from the token, never from an argument.
5. Never pass a client's token to an upstream API. Use a separate token issued to the server.
6. Make handles random and bound to the user; log who did what, with no tokens in logs.
7. Guard what you fetch: discovery URLs, client metadata, anything a stranger names. Resolve once, check, pin; block internal ranges and non-HTTPS.
8. Treat what you return as untrusted by the model. Keep descriptions short and static, version them so a host can pin, return data not instructions, and mark untrusted content in results.
9. Least privilege inside the server: a read-only database user, no shell, parameterised queries, rate limits.
10. Test the failures, not the happy path: each row of the tables in this module is a test.

A checklist

1. Say which transport and whether authorization applies. HTTP: follow it. stdio: environment credentials, and review the launch command.
2. Challenge correctly: 401 with resource_metadata and the minimum scope.
3. Validate every token five ways (signature, issuer, audience, expiry, scope). Reject tokens with no audience.
4. Refuse passthrough. One token per audience.
5. Use PKCE with S256, the resource parameter, state, and the iss check. Match redirect addresses exactly.
6. Take the user from the token. Bind handles to the user. Do not log tokens.
7. Guard every fetched URL and every URL you open. No shell.
8. Require consent per client if you proxy a third party.
9. Show tools in full, pin them, and re-check on change.
10. Gate the dangerous combination: after private or untrusted content, ask before anything that can send data out.
11. Test each attack in this module.

For the curious Status codes and who checks what

A missing or invalid token gets 401; a valid token with too few scopes gets 403. Scopes start minimal and step up when needed, because a broad list in the first challenge trains people to click through. Discovery fetches URLs the other side supplies, so it needs the same server-side request protections as any fetcher.