To secure an MCP server, authenticate every protected request, verify that each token was issued for that server, authorize each operation at the narrowest practical level, and isolate the code that runs in its environment. The right controls depend on whether the server uses local stdio, localhost HTTP, remote HTTP, or an MCP App. This checklist uses the Model Context Protocol Security Best Practices document at the 2025-11-25 documentation path, the MCP TypeScript SDK v1 documentation, and the specification release announced on 2026-07-28. Check the current specification and SDK documentation for the version you deploy: guidance in the older security document should not automatically be treated as a normative requirement of the newer release.
1. Map the deployment and its trust boundaries
Before choosing controls, record what is running, who can reach it, what data it can access, and what actions it can take. Treat the host or client, MCP server, authorization server, downstream APIs, and execution environment as separate trust boundaries.
| Deployment or component | Security questions to answer | Controls to consider |
|---|---|---|
| Local server over stdio | Which user launches it? What filesystem paths, processes, and credentials can it access? | Restrict process permissions and filesystem access; use a sandbox or container where appropriate. |
| HTTP server bound to localhost | Can a browser or untrusted local process reach it? Is the listener bound only to loopback? | Use the SDK’s documented DNS-rebinding protections for the framework and configuration in use; do not assume they apply when binding to all interfaces. |
| Remote HTTP server | How are callers authenticated? Which authorization server issues credentials? Which users and operations are allowed? | Validate tokens for this resource, enforce authorization at the HTTP boundary, and restrict network access where the threat model calls for it. |
| Server calling downstream APIs | Which credentials does the server hold, and can a tool access data belonging to another user? | Use credentials and permissions appropriate to the downstream operation; do not relay an unvalidated client token. |
| MCP App displaying UI | What remote content is rendered, what origins can the UI contact, and can it initiate tool calls? | Use the sandboxed iframe model, declare permitted origins, and keep tool-call approval under host control. |
Also inventory sensitive data, write or administrative actions, third-party API calls, and any untrusted content rendered or processed. These determine which controls need to be mandatory rather than merely defense in depth.
2. Authenticate and authorize requests
Validate what a token is for
For an HTTP server, verify tokens with a trusted verifier. Check validity, issuer, expiry, and the authorization claims your deployment requires. A syntactically valid bearer token is not enough: it must also be intended for this MCP server or resource. The Model Context Protocol Security Best Practices document states: “MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.”
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
The MCP TypeScript SDK v1 server documentation describes an expectedResource option. When configured, a token for a different resource—or one with no resource—is rejected with 401 invalid_token. Confirm the behavior and configuration in the SDK version you actually deploy.
Choose where authorization is enforced
Per-server authorization requires a valid authorization decision for every request to the server. Per-tool authorization can leave public tools available while requiring authorization for sensitive tools. Whichever model you use, enforce protection at the HTTP boundary for protected remote resources: return HTTP 401 with a WWW-Authenticate challenge so the client can discover and follow the authorization flow. A tool-level error alone does not provide that HTTP authorization challenge.
For sensitive handlers, check authorization again before performing the operation. Derive the user or account context from the authenticated identity rather than trusting an identifier supplied only as a tool argument, and ensure the caller is entitled to access the particular object named in the request.
Rank #2
Keep credentials inside their intended boundary
Do not pass a client’s access token through to a downstream API as a convenient proxy credential. Validate credentials for the MCP resource, then use an appropriate server-side authorization design for downstream access. Token passthrough can confuse the recipient about who the token was issued to and which resource it authorizes.
3. Apply least privilege to scopes and tools
Start with the smallest useful permission set. Separate read, write, administrative, and unrelated data access rather than bundling them into a broad connection-time grant. The security guidance warns against wildcard or omnibus scopes such as *, all, or full-access, and against publishing every possible scope when it is not needed.
- Define a narrow baseline. Request only permissions needed for ordinary, low-risk operations.
- Elevate at the point of need. When a user invokes a protected operation, request the specific additional permission through an authorization challenge instead of asking for it at initial connection.
- Enforce the operation in the handler. A scope or token claim is not by itself proof that the caller may perform every action or access every referenced object.
- Make consent legible. Describe the requested permission in terms the user can recognize, including the protected action or data involved.
- Record elevation where required. Keep an audit record of scope elevation details and a correlation ID when the deployment’s audit requirements call for it.
Least privilege applies at both levels: the authorization scope limits broad capabilities, while tool-level checks constrain what a particular operation can do with them.
4. Sandbox the code that actually runs
MCP Apps: isolate the UI
MCP Apps use sandboxed iframes to restrict host access. Use the documented model with predeclared templates, auditable messages, and host-controlled approval for UI-initiated tool calls. Declare network origins in CSP metadata, distinguishing connection targets from resource origins. In the documented model, the host uses those declarations to constrain connections, and unspecified external connections are blocked.
Local stdio servers and proxies: isolate the process
An iframe sandbox does not isolate a local MCP server executable. For locally spawned stdio servers or proxies, restrict filesystem access and process permissions; use sandboxing or containerization where appropriate; and require additional authorization for dangerous commands. The security guidance frames these as SHOULD-style proxy controls for this scenario, so assess them against the deployment’s actual risks and applicable requirements.
Keep the boundary distinction explicit in reviews: an iframe limits what UI code can reach; process or container isolation limits what server-side code can reach. Depending on the architecture, both controls may be needed.
Rank #4
5. Protect local and network boundaries
Reduce exposure of localhost services
Localhost HTTP services can be targeted through DNS rebinding. The MCP TypeScript SDK v1 server documentation describes protections in createMcpExpressApp() for localhost and loopback configurations, and warns that binding to 0.0.0.0 does not automatically enable that protection. Verify the actual listener address and framework setup rather than assuming a localhost safeguard is active.
Defend OAuth metadata discovery against SSRF
Authorization metadata discovery can cause a client to fetch attacker-controlled URLs. The MCP Go SDK lifecycle documentation describes HTTPS enforcement, rejection of private or link-local destinations, redirect validation, and DNS-rebinding-aware checks. It also warns that custom HTTP transports can bypass some defaults, leaving protection to the caller. If you replace a default transport, review its URL validation and redirect behavior explicitly.
Constrain outbound traffic
Validate redirect destinations and do not blindly follow redirects that could lead to internal resources. Where the threat model warrants it, add egress proxies or network policies to limit which destinations server-side clients can contact. Treat these controls as an additional layer, not a substitute for validating the URL and authorization decision in the application.
Free tools Windows power users keep installed
One-click scans. No signup required.
6. Secure sessions and authorization flows
- Authorize every inbound request. A session ID identifies a session; it does not prove the caller is authenticated or authorized.
- Use unpredictable session identifiers. Generate secure, hard-to-guess IDs, and bind a session to the authenticated user identity where applicable.
- Protect the OAuth round trip. Use secure, random, single-use
statevalues and exact redirect URI matching. - Validate the authorization response issuer. The specification release announced on 2026-07-28 says clients must validate the authorization response
issparameter in accordance with RFC 9207.
7. Use this deployment review checklist
- Have you documented whether the server uses stdio, localhost HTTP, or remote HTTP, and identified its data, write actions, and downstream services?
- Does every protected HTTP request use a trusted token verifier that checks validity and whether the token is intended for this MCP resource?
- Do protected remote resources return HTTP 401 with a
WWW-Authenticatechallenge rather than relying only on a tool-level error? - Are permissions narrow at both the scope and tool levels, with elevation only when a protected operation needs it?
- Do handlers independently check the requested operation and the caller’s access to the referenced user or object?
- Are client credentials kept from downstream APIs unless an explicit, safe authorization design requires otherwise?
- Are UI iframe restrictions and server-process isolation reviewed as separate controls?
- Have you checked localhost binding, metadata-discovery URL validation, redirect handling, and any custom HTTP transport?
- Are authorization decisions made on every request, with secure session IDs and user binding where applicable?
- Do the protocol and SDK versions in use support the assumptions in the implementation, and have you checked their current authorization guidance?
8. Track version changes without treating plans as requirements
The 2026-07-28 specification release announcement describes RFC 9207 issuer validation and a shift in the preferred direction for client registration toward client metadata documents. Confirm the applicable current specification and implementation guidance when updating a client or server; do not assume a release announcement alone describes every migration detail.
The MCP roadmap discusses agent identity, proof-of-possession adoption, workload identity federation, and delegation as development priorities. These are roadmap directions, not settled checklist requirements solely on the basis of that roadmap. Keep them separate from controls already documented for the versions you deploy.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
