Does Your MCP Server Work in the Browser?

Browser CORS compatibility determines whether an MCP server can be used from web-based tools. When a server lacks CORS headers, browsers block all connections to it. Chrome extensions, cloud AI platforms, and web apps cannot use the server, even if it works perfectly from desktop clients.

What is CORS?

CORS (Cross-Origin Resource Sharing) is a browser security feature. When a web page at app.example.com tries to call an API at mcp-server.example.com, the browser first asks the server: "Do you allow requests from this origin?" If the server doesn't respond with the right headers, the browser blocks the request entirely.

Why this matters for MCP

The MCP ecosystem is split between two types of clients:

• >Desktop apps (Claude Desktop, Cursor, VS Code) connect server-side and are not subject to CORS
• >Web-based tools (cloud platforms, Chrome extensions, browser AI agents) must go through the browser and are subject to CORS

If your MCP server doesn't support CORS, it's invisible to the entire web-based ecosystem.

What gets blocked without CORS

Cloud AI platforms that connect from the user's browser, Chrome extensions that add MCP capabilities to web apps, web-based AI agents and chatbots, browser-based developer tools like this security scanner, and any web application that needs to call your MCP server client-side.

What still works without CORS

Claude Desktop, Cursor, and VS Code extensions all connect server-side, so they're unaffected. Same for server-to-server calls from backend services.

How to add CORS support

Add these headers to your MCP server's HTTP responses:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, mcp-session-id

Most MCP server frameworks (like the official TypeScript SDK) have CORS configuration options. Check your framework's documentation for the specific setting.

Is missing CORS a security issue?

It depends on where the server runs. For remote/cloud MCPs, missing CORS is a compatibility limitation, not a security vulnerability. Restrictive CORS is a valid choice for servers that only need desktop clients.

But permissive CORS on a local MCP is a different story entirely.

DANGER: Permissive CORS on local MCPs

If you run an MCP server on your own machine (localhost, 127.0.0.1) and it uses Access-Control-Allow-Origin: *, you are exposing your computer to the entire internet.

Here's how the attack works:

1. 1.You run a local MCP at http://localhost:8080/sse that gives your AI access to local files
2. 2.You browse the web and land on malicious-website.com
3. 3.Hidden JavaScript on that site tries to connect to http://localhost:8080/sse
4. 4.Because your MCP uses Access-Control-Allow-Origin: *, the browser allows the connection
5. 5.The malicious site silently executes MCP tools (read_file, execute_bash) on your machine

This is not theoretical. Any website you visit can probe common localhost ports. If your local MCP answers with permissive CORS, your files, databases, and terminal are wide open.

The fix: local MCPs must restrict CORS to specific trusted origins (like http://localhost:3000 for your own app), or disable CORS entirely and rely on desktop clients only.

CORS for remote MCPs is different

For cloud-hosted MCPs (like https://bgpt.pro), permissive CORS is usually fine, even necessary. Web-based AI chat interfaces need CORS to connect. The server is already public, and authentication (via Authorization headers) protects against unauthorized use. The risk falls on the MCP developer (unauthorized domains pinging their server), not on the end user.