MCPCore
← Back to blog
·By MCPCore Teammcpsecuritychecklistauthentication

The MCP Server Security Checklist

A practical, updated checklist for securing an MCP server before you expose it to a real AI client, covering authentication, input validation, rate limiting, and the 2026-07-28 spec's authorization changes.

An MCP server is a real HTTP endpoint that executes code on behalf of an AI model deciding autonomously what to call and when. That makes security review non-optional before exposing a server beyond your own machine. This is a practical checklist, not a theoretical one: work through it before you share an endpoint with anyone.

Authentication

  • Authentication is required by default. Public, no-auth mode should be a deliberate decision for specific non-sensitive tools, not the default state of a server you forgot to lock down.
  • If you use OAuth, you're conforming to OAuth 2.1. The current MCP spec formally treats OAuth-supporting servers as OAuth 2.1 resource servers. If you rolled your own OAuth implementation before this was tightened, revisit it.
  • Authorization servers return the iss parameter (RFC 9207), and your client validates it. This is a specific, spec-mandated defense against OAuth mix-up attacks added in the 2026-07-28 revision. If your OAuth flow predates this, check it explicitly.
  • API keys are decoupled from URLs. A secret embedded in the URL itself (an "unlisted" server) shows up in logs, browser history, and anywhere the URL gets recorded. Prefer an Authorization: Bearer header for anything beyond quick, single-user sharing.

Input Validation

  • Every tool input is validated against the declared schema, not just checked for the right shape. JSON Schema validation confirms structure; it does not confirm that a date range isn't absurdly large or that an ID actually belongs to the requesting user.
  • Ranges and limits are capped explicitly. An AI can ask for unbounded data. Always cap query ranges, page sizes, and result counts server-side.
  • SQL queries use parameterised statements, with no string interpolation of tool arguments into a query string, ever.
  • Outputs are sanitized. Don't return internal IDs, tokens, or fields the caller doesn't need just because they happen to be in the database row.

Rate Limiting

  • Rate limiting is configured per server, not left to whatever default your hosting environment happens to apply.
  • Limits are keyed by API key or authenticated identity, not by IP, since many calls from the same AI client host can otherwise look identical.
  • Write operations are limited more aggressively than reads. A runaway loop calling a read-only tool is annoying; one calling a tool that writes data or sends messages is a real incident.

Secrets

  • No credentials in source code. API keys, database passwords, and tokens live in environment variables or an encrypted secrets store, never hardcoded.
  • Secrets are never returned in tool output, including error messages. A stack trace that leaks a connection string is a common, avoidable mistake.
  • Secrets are encrypted at rest. If you're on a managed platform, confirm what encryption standard it uses. MCPCore encrypts secrets with AES-256 and references them in tool code as env.MY_KEY without exposing the raw value anywhere in logs.

Observability

  • Every failed tool call is logged with its full context: input parameters, stack trace, and timestamp. Debugging a production incident without this is guesswork.
  • Error messages returned to the AI don't leak implementation details. Use isError: true in the tool result with a clean message, not an uncaught exception with an internal stack trace.
  • You have visibility into request volume and origin, so an unusual spike is something you'd actually notice.

Transport

  • The server is behind HTTPS with a valid, non-self-signed certificate. AI clients and most Streamable HTTP implementations won't reliably connect to plain HTTP in production.
  • Legacy HTTP+SSE transport is on your radar for retirement. It's deprecated as of the 2026-07-28 spec with a one-year offramp. Not urgent, but worth tracking if your server still uses it.

Before You Share the URL

Run through this list every time you're about to hand an endpoint to someone outside your own testing loop, not just once when the server is first built. Tool code changes, and a validation check that was sufficient for the first version of a tool isn't automatically still sufficient after you add a new parameter.

If you'd rather have most of this handled for you, MCP server security covers how MCPCore's four built-in authentication modes, encrypted secrets, and per-server rate limiting apply this checklist by default, without custom code.

This checklist reflects the current MCP specification, including the authorization changes introduced on 2026-07-28. Check modelcontextprotocol.io for the authoritative and most current security guidance.