-
Notifications
You must be signed in to change notification settings - Fork 9.1k
Open CORS for any origin to allow direct browser connection #2725
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
domdomegg
merged 8 commits into
modelcontextprotocol:main
from
cliffhall:open-cors-for-direct-connect
Sep 19, 2025
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
1979e68
* In src/everything/sse.ts
cliffhall 921e2f7
* In package.json and package-lock.json
cliffhall 0ea3756
Add caution note for CORS origin wildcard usage
evalstate bf68938
* In streamableHttp.ts
cliffhall 215e0e4
* In streamableHttp.ts
cliffhall 972bb43
* In sse.ts
cliffhall 635db36
* In sse.ts
cliffhall 1366abd
Merge branch 'main' into open-cors-for-direct-connect
cliffhall File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we restrict this at least a little to
localhost:6274?The reason we need this is only to allow the inspector to work right? I think it's a little too easy for folks to copy paste this server as a starting point and end up with a too permissive CORS policy without ever seeing this comment.
Maybe a comment
// enables inspector to connectinstead? Would that work for your demo use case?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could but is there an actual reason for this? In the auth-wg-devx meeting earlier we discussed this and no one could think of a reason why it shouldn't be fully open. If you curl this or use a desktop client, you don't have the cors blocking. There's no obvious XSS vector. And also there was discussion about hosting a version of the inspector. If that happened, then it wouldn't be from that URL. Further, if someone is running the inspector in a container and has chosen to expose 6274 on a different host port, you have a problem.
Finally, in the hosted version of this server that the core team forked to work on an auth example, they have it fully open:
https://github.com/modelcontextprotocol/example-remote-server/blob/main/src/index.ts#L101
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added
// Enable CORS for all routes so Inspector can connectas a comment in both sse.ts and streamableHttp.ts and also// use "*" with caution in productionThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not enough of a security expert to push back hard here, but I'm just reminded of the vulnerability we had originally addressed with modelcontextprotocol/inspector@50df0e1 hence asking the question here to be sure.
I believe if you visit
evil-website.comwhile you have your local unauthed dev server running, it could theoretically make requests to it and execute tools with this approach (assuming it knows the port - it might try common ones like 8000 and 8080).If you've discussed this in
auth-wgand we're also giving this as an example remote server, those are convincing points to not block here for me.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@felixweinberger The vulnerability you mention was with the proxy and had two prongs: 0.0.0.0 DNS rebinding that allowed
evil-website.comto momentarily change its DNS to point to 0.0.0.0 causing the proxy to think it was actually our inspector, AND being able to tell the proxy to run an arbitrary shell command as an stdio server with the query string.Having
cors('*')in this example server doesn't equate to that possibility. Something in the browser could connect and execute tools if it knew you had a server there (i.e., the inspector), or it could probe as you suggested. But you wouldn't leave an http mcp server up and running locally for anything but testing purposes. STDIO servers, you'd run locally, but those would not be accessible in this way but rather run within local processes, such as the proxy, which is now locked down on that front.I do think that the comments about using cors('*') with caution in production should be enough for this example server.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough!