Guide to Securing MCP AI Servers 2of2

MCP AI Server Security, part 2 of 2

Continue from part #1 of MCP AI Server Security 1 of 2

The landscape of Artificial Intelligence (AI) is evolving rapidly, with agentic AI leading the charge—intelligent systems designed to autonomously achieve goals and act on behalf of users. This shift calls for a reliable, standardized approach to enable AI agents to seamlessly interact with external data sources and services. Enter the Model Context Protocol (MCP), a groundbreaking standard that fosters interoperability, moving away from isolated integrations toward a unified AI ecosystem.

Dubbed the “AI USB port,” MCP serves as a versatile interface, connecting Large Language Models (LLMs) and their applications to a variety of systems—think enterprise databases, local files, web APIs, and external tools. This connectivity boosts development speed and equips AI agents with real-time insights, surpassing the limits of their original training data.

Yet, this expanded connectivity brings forth new security challenges. MCP’s open, integration-friendly design creates a broader attack surface that developers must address proactively. Security now extends beyond individual applications to every MCP server in the network. This guide offers a detailed, layered defense strategy for architects and engineers, covering the entire security process—from initial design and threat analysis to secure coding and operational excellence—ensuring a safe platform for agentic AI innovation.

Exploring the MCP AI Server Threat Environment

Securing an MCP AI server starts with a clear grasp of its unique vulnerabilities. This threat environment combines risks from the AI layer, API infrastructure, and communication protocols, revealing a complex security landscape that demands careful attention.

1.1 Decoding the MCP Architecture and Core Elements

The Model Context Protocol (MCP) is an open framework that standardizes how applications deliver context to LLMs, paving the way for advanced workflows and intelligent agents. Understanding its structure and components is key to identifying and mitigating potential security gaps.

Fundamental Architecture

MCP relies on a client-server model with three essential components:

• MCP Host: The primary AI-driven application users interact with, such as development environments like Cursor, desktop tools like Claude Desktop, or custom AI solutions. It oversees the user interface and manages links to multiple MCP servers.

• MCP Client: Integrated into the MCP Host, this component establishes a dedicated, one-to-one connection with a single MCP server. A host can support multiple clients simultaneously, aggregating diverse capabilities and context from various servers.

• MCP Server: A streamlined program that exposes specific functions through the MCP interface. These servers can operate locally to access device-based files or services, or remotely to tap into web APIs and online resources.

Communication Framework

Client-server interactions follow the JSON-RPC 2.0 standard, utilizing message types like requests, responses, notifications, and errors. The transport layer adapts to the deployment type: local servers use standard I/O (stdio) processes, while remote servers leverage HTTP streams such as Server-Sent Events (SSE) or WebSockets for interactive use.

Securing Real-Time Communication with WebSockets

For MCP servers that require interactive, bidirectional communication, WebSockets are the de facto transport layer. However, the flexibility and performance of WebSockets come with a unique set of security challenges that must be addressed to protect the communication channel between the client and the server.

2.1. WebSocket Security Fundamentals: From ws:// to wss://

The foundational security measure for any WebSocket-based application is the use of encryption. The WebSocket protocol defines two schemes:

• ws://: An unencrypted, plaintext communication channel.
• wss://: WebSockets secured with Transport Layer Security (TLS), the same encryption that powers HTTPS.

Using the unencrypted ws:// protocol in any production environment is a critical vulnerability. It exposes all traffic to eavesdropping and Man-in-the-Middle (MITM) attacks, where an attacker can intercept, read, and modify all data exchanged between the client and the server. 

Therefore, the use of wss:// is non-negotiable for all MCP server connections that traverse untrusted networks. TLS encryption provides essential confidentiality and integrity for the data in transit. Moreover, modern web browsers now enforce this practice, often blocking insecure WebSocket connections from pages loaded over HTTPS, making wss:// a prerequisite for both security and functionality.

2.2. Authentication and Authorization Patterns for WebSockets

A significant challenge in securing WebSockets is that the protocol itself does not handle authentication or authorization. An even greater complication is that the standard browser WebSocket API in JavaScript does not allow developers to set custom HTTP headers, such as the Authorization header typically used for sending Bearer tokens. This limitation forces developers to adopt alternative patterns to authenticate connections.

The choice of an authentication method involves a direct trade-off between implementation simplicity and the level of security provided. The most straightforward, stateless methods tend to introduce security risks like credential leakage, while the most secure methods are inherently stateful and add architectural complexity. Teams must consciously evaluate this trade-off based on their application’s risk profile. A low-risk internal tool might accept the risks of a simpler method, whereas a public-facing, high-stakes application must invest in the complexity of a more robust, stateful pattern.

Several patterns have emerged to solve this problem:

Method 1: Token in Query Parameter

In this widely used approach, the client first authenticates with a standard HTTP endpoint to obtain a short-lived credential, typically a JSON Web Token (JWT). This token is then appended as a query parameter to the WebSocket connection URL.

• Flow: wss://mcp.example.com/ws?token=eyJhbGciOiJIUzI1Ni...
• Pros: Relatively simple to implement on both client and server. The server can perform a stateless validation of the token during the initial HTTP upgrade request.
• Cons: This pattern carries a significant security risk. URLs are often logged in plaintext by various components in the network path, including reverse proxies, web servers, and security information and event management (SIEM) systems. This can lead to the accidental leakage of the token, allowing an attacker who gains access to these logs to impersonate the user.

Method 2: Token as First Message

This pattern avoids placing the token in the URL. The client establishes an initially unauthenticated WebSocket connection and then immediately sends the token as the first data message over the established channel.

• Flow:
  1. Client connects to wss://mcp.example.com/ws.
  2. Client sends message: {"type": "auth", "token": "eyJhbGciOiJIUzI1Ni..."}.
  3. Server validates the token. If valid, the connection is marked as authenticated; otherwise, it is terminated.
• Pros: More secure than the query parameter method, as the token is not exposed in URLs or logs.
• Cons: Introduces statefulness on the server, which must manage the authentication status of each connection. It also creates a vulnerability to a DoS attack where an attacker opens thousands of connections but never sends an authentication message, consuming server resources.

Method 3: Ticket-Based Authentication (Recommended for High Security)

This is a highly secure, stateful pattern that mitigates the risks of the other methods by using a single-use, ephemeral credential.

• Flow:
  1. The client makes a standard, authenticated HTTP request to a dedicated endpoint (e.g., /api/ws-ticket).
  2. The server generates a unique, random, and short-lived “ticket.” It stores this ticket in a fast cache (like Redis), associating it with the authenticated user’s ID and potentially their IP address.
  3. The server returns the ticket to the client.
  4. The client initiates the WebSocket connection, passing this single-use ticket in the query parameter: wss://mcp.example.com/ws?ticket=....
  5. The server receives the upgrade request, looks up the ticket in its cache, validates that it exists, has not expired, and matches the requesting user/IP, and then immediately deletes the ticket from the cache to prevent replay attacks. If validation succeeds, the connection is upgraded and considered authenticated.
• Pros: Extremely secure. The credential is single-use and expires quickly, drastically reducing the risk if it is leaked.
• Cons: This is the most complex pattern to implement, as it requires an additional server-side component (the ticket-issuing endpoint) and a state store (the cache) for managing the tickets.

The following table provides a comparative overview of these authentication methods.

Comparison of WebSocket Authentication Methods

2.3. Thwarting Hijacking Attempts: Preventing Cross-Site WebSocket Hijacking (CSWH)

Cross-Site WebSocket Hijacking (CSWH) is a specific and dangerous attack that leverages a Cross-Site Request Forgery (CSRF) vulnerability on the WebSocket handshake process.

Attack Vector Explained

The attack unfolds as follows :

1. A victim is logged into a legitimate website that uses WebSockets (e.g., mcp-server.com). Their browser holds a valid session cookie for this domain.
2. The victim is tricked into visiting a malicious website controlled by an attacker (e.g., evil-site.com).
3. The attacker’s page contains JavaScript code that silently initiates a WebSocket connection to the vulnerable MCP server (wss://mcp-server.com/ws).
4. Because the WebSocket handshake is an HTTP request, the victim’s browser automatically attaches the session cookie for mcp-server.com to this cross-origin request.
5. If the server relies solely on this cookie for authentication, it will establish a fully authenticated WebSocket connection.
6. The attacker’s script on evil-site.com now has full, two-way control over this hijacked connection, allowing them to send messages on the victim’s behalf and read any sensitive data sent back by the server.

Mitigation Strategies

Preventing CSWH requires breaking the chain of trust that the attacker exploits. The following controls are essential:

• Origin Header Validation: This is the most critical defense mechanism. The Origin HTTP header indicates the domain that initiated the request. During the handshake, the server must inspect this header and compare it against a strict allowlist of trusted domains (e.g., the domain of the legitimate client-side application). If the value in the Origin header is not on the allowlist, the server must reject the connection request immediately.
• Anti-CSRF Tokens: For the highest level of assurance, the WebSocket handshake should be protected with a standard anti-CSRF token, just like a secure web form. The client application would first fetch a unique, unpredictable token from a server API and then include this token in the WebSocket handshake request (e.g., as a query parameter). The server would then validate that this token is valid for the user’s session before upgrading the connection.

Continue here: Secure MCP Server with Python and NextJS