Just for reference, this GitHub follows in the tradition of many an example project all of which have the explicit intent of demonstrating not that the underlying concept is inherently vulnerable, but that implementations can be.

Damn Vulnerable Web App is probably the best known, but there are others for REST apis, web sockets, GraphQL, and more. They’re educational reference implementations that are deliberately insecure to use as an educational tool.

If a Damn Vulnerable Web App demo was just 10 or 20 different “there no authn/authz on this endpoint”, it would be a crappy demo

The MCP uses some kind of identity to talk to booking.com or GitHub. That's your security boundary. You assume that anything the MCP has access to (including that identity), the user has access to. If you add a `list_available_hotels()` tool to your booking.com MCP, that tool needs to run with the same identity as the person talking to the LLM. It doesn't have any more permissions or access to your system than the booking.com react app does.

Think of the MCP server as a natural language interface to your application. Like a CLI or a WebApp. Instead of writing specific commands to a cli, or following a series of clicks in a GUI app, you "chat" with it.

I was responding to you saying that the security model is different because servers can be treated as client applications for the security model, but that doesn't make sense for third party servers that you aren't hosting and just sending/receiving data from.

From the client PoV, booking.com could return malicious information to my prompt telling it to do unauthorized things with my computer(e.x. upload banking cookies to a remote endpoint). This doesn't sound secure, and just saying "it's part of the client" doesn't change that.

Like, what if google decided to blow their multibillion dollar company to steal my banking cookies?!?!

“Attackers are using (email attachments, SMSs, TeamViewer, crypto wallet, phishing websites, etc) to access your private data - they can […] you using tricks to make it seem legit”

The only difference is that AI/MCP is the current flavor of the month for this type of attacks. These attacks get much worse when the tech has the hype (like AI now or limewire 20 years ago or the internet 30 years ago) and the average user still doesn’t quite fully grasp what this tech is doing or how it’s working.

This is distinct from various forms of phishing where they are tricking you to give access to sensitive information. Here, you are giving that access willingly to something that is then itself vulnerable to being tricked/tricking you.

Would take decades to recover from that mistake that was JavaScript (and TypeScript)

correct me if im wrong, but isnt that a proxy? why is everyone calling it a server

If you squint hard enough you can call almost any server a proxy. An FTP server is a proxy for data on disk. Github.com is a proxy for a git repo.

But yeah, saying "MCP is a proxy to your application" might be more insightful than "MCP is a client to your application"

i think this whole "mcp security is terribad" thing spawns from the incorrect categorization of the thing as a "server" - if it were instead called a proxy, the rabble would die down.

Could also be called a gateway, which feels a bit more accurate.

The same way API gateways perform additional services like rate-limiting and authentication and billing, an MCP gateway abstracts the services behind it and adds context such that an LLM can more easily interact with them.

Only if the MCP is explicitly programmed that way. Or I'm misunderstanding what you mean

With that said, some vulnerabilities like command injections or argument injection, the responsibility is on MCP developer to make sure they follow best practices and not let user take control of these commands when "shelling out".