No credentials in the endpoint URL
Authored by Stanley Hong · AgentReserve (founder).
The endpoint URL has no userinfo segment and no token-like keys (`token`, `api_key`, `apikey`, `access_token`, `refresh_token`, `password`, `secret`, `client_secret`) in its query string. Credentials in URLs leak through logs, Referer headers, browser history, and intermediary caches.
When this rule runs
Evaluated on every scan — observable from the URL, TLS handshake, or HTTP response headers, even when the MCP layer is auth-walled or unresponsive.
Why it matters
URLs end up in access logs, Referer headers, browser history and proxy caches. Anything sensitive in the URL is effectively semi-public — a single shared link or screenshot can be enough to compromise the credential.
Pass condition
The endpoint URL contains no `user:pass@` userinfo and no token-like query parameter keys.
Fail condition
The endpoint URL has a userinfo segment or a query parameter that looks like a credential.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"hits": [{"location": "query", "key": "api_key"}]}
Remediation
Move credentials out of the URL — into request headers, server-side configuration, or a proper OAuth flow. Rotate any credential that has appeared in a URL.
Methodology
This rule belongs to the Endpoint hygiene dimension. Properties of the URL itself: whether the host is intended for public use, whether secrets appear in the URL, and other observable URL-level signals.
Read the full methodology for how rules are aggregated into a score, how verdicts are decided, and how hard-fail rules override the aggregate.