MCP server is reachable without authentication
An MCP server is responding at a public URL to requests carrying no credentials (HTTP 2xx).
Why it matters
An MCP server is responding at a public URL to requests carrying no credentials (HTTP 2xx). An MCP server exists to expose tools and data to an AI agent, so whatever it exposes — database queries, file access, internal APIs, a customer knowledge base — is now available to anyone who points their own agent at this URL, with your infrastructure doing the work and your accounts paying for it. It is also self-describing by design: an unauthenticated client can ask it to list its tools and learn exactly what it can be made to do. This scan only issued a plain GET, so it has not enumerated your tools — but anyone else can.
How ShipReady detects it
AI-specific exposure — the product's differentiating module. Covers two distinct failure modes of AI-built applications: 1. Tooling artifacts deployed by accident. AI coding tools generate config and instruction files at the repo root; developers who push a whole repo (rather than just its build output) to static hosting serve them publicly. Some are merely instructions; others hold live API keys. 2. Secrets promoted into the client bundle via a PUBLIC env var prefix. This is the single most characteristic AI-app mistake: AI assistants correctly explain that a variable must be prefixed (NEXT_PUBLIC_, VITE_, ...) to be readable in the browser, and developers apply that prefix to a *server* secret. The bundler then inlines the real value into JavaScript that anyone can read. Both are confirmed by observation, never inferred from framework fingerprints alone.
Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.7.0.
How to fix it
This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.
An MCP server at a public URL answers requests that carry no credentials, so anyone can point their own AI agent at it and use whatever tools and data it exposes. Put authentication in front of it before anything else: the MCP specification's HTTP transports support OAuth 2.1 with a protected-resource challenge, so require a bearer token and return 401 to anonymous requests — most MCP server frameworks accept an auth handler or middleware for exactly this. If the server only ever needs to serve your own backend, do not expose it on the public internet at all: bind it to localhost or a private network and reach it server-to-server. Then review what it actually exposes: audit the registered tools and remove any that read customer data, write to a database, or call a paid API unless they genuinely need to be reachable this way, and scope the credentials the server itself runs with to the minimum those tools require. Assume the current tool list is already public — an unauthenticated MCP server will describe its own capabilities to anyone who asks.
Frequently asked questions
- What does "MCP server is reachable without authentication" mean?
- An MCP server is responding at a public URL to requests carrying no credentials (HTTP 2xx).
- How serious is it?
- ShipReady rates this high. Fix before launch. A real weakness that an attacker can act on.
- How do I fix it?
- Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.
- Can I check my own site?
- Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.
Related checks
Run this check on your site
ShipReady checks this and 193 other things across up to ten pages of your site, with an AI-ready fix for each. Free, no signup.