T09 · Insecure Skill Coding Practices
- Location
SKILL.md:34- Finding
API Key Exposed Through MCP URL Query Parameter
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 34–36 and 74–76
Vulnerability Type: Credential exposure through URL query parameters
Risk Level: MediumVulnerable Code
bash claude mcp add --transport http pharma_intelligence \ "https://connect.patsnap.com/096456/Logic-mcp?apiKey=sk-xxxxxxxxxxxx"The same insecure pattern is repeated in the connection-error guidance:
bash claude mcp add --transport http pharma_intelligence \ "https://connect.patsnap.com/096456/Logic-mcp?apiKey=YOUR_API_KEY"Technical Analysis
The setup instructions require users to embed a PatSnap API key directly in the MCP server URL. Although the endpoint uses HTTPS and therefore encrypts the request in transit, placing credentials in a URL query string creates additional exposure surfaces. The complete URL may be retained in:
- Shell command history
- Process command-line metadata
- MCP client configuration files
- Proxy and server access logs
- Diagnostic output, telemetry, and error reports
- Screenshots or copied setup commands
Authentication to the declared PatSnap service is necessary for the Skill's biomarker and patent research functionality. However, exposing the credential through a query parameter is not the minimum-risk authentication mechanism. The service must receive an authentication secret, but unrelated local users, logging systems, and infrastructure components do not need access to it.
The visible
sk-xxxxxxxxxxxxvalue is an example placeholder rather than a confirmed live secret. The vulnerability arises because the documentation directs users to replace it with a real credential while retaining the insecure URL-based transport pattern.Attack Path
- A user follows the setup instructions and substitutes a valid PatSnap API key into the URL.
- The complete command or resulting URL is retained in shell history, process metadata, an MCP configuration file, or infrastructure logs.
- An attacker with access to ...[truncated 1048 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not place API credentials in URL query parameters.
- Prefer an MCP client secret field, protected environment variable, operating-system credential store, or dedicated secret manager.
- Transmit the key through an authorization header, such as
Authorization: Bearer ..., where supported. - Ensure secret-bearing configuration files use restrictive filesystem permissions and are excluded from source control.
- Redact credentials from client errors, telemetry, debug traces, and server or proxy logs.
- Avoid displaying real keys in terminal commands where process inspection or shell-history capture is possible.
- Rotate any API key previously configured using the documented URL pattern and review relevant logs for unintended disclosure.
- If the service currently accepts authentication only through query parameters, update the service and MCP integration to support header-based or protected client-side credential injection.
