T09 · Insecure Skill Coding Practices
- Location
EXAMPLES.md:134- Finding
API Credential Exposed Through URL Query Parameters
- Content
View full analysis
Vulnerability Details
File Location:
EXAMPLES.md:134-142
Additional Locations:README.md:96,SKILL.md:223
Vulnerability Type: API key disclosure through URL query parameters
Risk Level: MediumVulnerable Code
javascript let query = "?token=" + apiKey; if (symbol) query += "&symbol=" + encodeURIComponent(symbol); if (isin) query += "&isin=" + encodeURIComponent(isin); if (cusip) query += "&cusip=" + encodeURIComponent(cusip); const url = "https://finnhub.io/api/v1/stock/profile2" + query; try { const res = await fetch(url);The same unsafe authentication pattern is also promoted as a supported general pattern:
javascript "?token=" + apiKeyTechnical Analysis
The generated example interpolates a secret API key directly into the request URL. Although the corresponding MindStudio configuration field is declared as a
secret, that protection applies only while the value remains in configuration storage. Once inserted into a URL, the credential may be captured by infrastructure that records request URLs.Potential exposure points include application diagnostics, proxy and gateway logs, observability platforms, exception reports, network monitoring systems, and provider-side access logs. TLS protects the URL while it is in transit but does not prevent either endpoint or authorized intermediaries from recording it.
The behavior is related to the Skill's declared API-integration functionality and does not represent an unrelated exfiltration channel. Nevertheless, teaching query-string authentication as a general pattern exceeds the safest minimum disclosure necessary when an API supports header-based authentication.
The flagged
btoa(user + ":" + pass)pattern elsewhere in the documentation is conventional HTTP Basic authentication encoding. It is not evidence of covert encoding or an independent exfiltration vulnerability.Attack Path
...[truncated 1259 chars]
- Remediation
View remediation
Remediation Suggestions
-
Prefer an authorization header whenever the target API supports one:
javascript const res = await fetch("https://api.example.com/endpoint", { headers: { "Authorization": "Bearer " + apiKey } }); -
Do not present query-string authentication as a general-purpose authentication pattern in
README.mdorSKILL.md. Document it only for APIs that explicitly require it. -
Where query authentication is unavoidable:
- Display a clear warning that the URL contains a secret.
- Use a dedicated, least-privileged API key.
- Prefer short-lived or readily rotatable credentials.
- Disable URL logging where possible.
- Configure proxies, gateways, error trackers, and monitoring systems to redact sensitive query parameters such as
token,key,api_key, andaccess_token. - Never include the complete request URL in
ai.log(), exceptions, or diagnostic output.
-
Add generation rules requiring header-based authentication by default and requiring explicit confirmation before generating query-parameter credentials.
-
Update the Finnhub example to follow the provider's safest supported authentication mechanism. If Finnhub mandates a query token for that endpoint, preserve the required behavior but add provider-specific warnings and log-redaction guidance.
-
Add a generated-code review check that detects secrets interpolated into URLs before presenting the final MindStudio function.
-