T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:40
- Finding
- API Credential Exposed Through URL Query Parameters## Vulnerability Details **File Location**: `SKILL.md`, lines 40–43 **Vulnerability Type**: API credential exposure through insecure request construction **Risk Level**: Medium ### Vulnerable Code ```text 1. POST /api/keys/create { walletAddress: "0x..." } → returns apiKey 2. Send USDC/USDT to the receiving address shown at agentcanary.ai (Base, Ethereum, Arbitrum, Optimism, Polygon) 3. POST /api/billing/check { apiKey: "..." } → auto-detects payment, credits account 4. Use endpoints: GET /api/data/realtime-prices?apikey=YOUR_KEY ``` ### Technical Analysis The documented usage pattern places the API key in the query string of a GET request. TLS protects the request while in transit, but it does not prevent the complete URL from being captured by HTTP client diagnostics, reverse-proxy and access logs, observability platforms, browser history, screenshots, or error reports. This practice also undermines the Skill's claim that API keys do not pass through the LLM context. An agent following the example may interpolate the credential into a URL within its generated tool arguments or conversation context, making the secret visible to model infrastructure and tool-call logging. The network communication itself is necessary for the declared API-only market-intelligence functionality. The security issue is the credential transport mechanism, not the use of the AgentCanary API. ### Attack Path 1. A user creates and funds a wallet-linked AgentCanary API key. 2. An agent follows the documented example and inserts the key into the `apikey` query parameter. 3. A client, proxy, monitoring service, tool-call trace, or access log records the complete request URL. 4. An attacker or unauthorized operator with access to that record extracts the API key. 5. The attacker submits requests under the victim's account until the key is revoked, its credits are depleted, or server-side limits intervene. ### Impact Assessment A dis ...[truncated 530 chars]
- Remediation
- ## Remediation Suggestions 1. Replace query-string authentication with an HTTP authorization header, such as: ```http Authorization: Bearer <API_KEY> ``` A dedicated secret header is also acceptable if bearer authentication cannot be supported. 2. Update all documentation and endpoint examples to prohibit credentials in URLs. 3. Inject the API key directly from a protected secret store into the HTTP header so the model does not need to read, reproduce, or interpolate it. 4. Configure HTTP clients, proxies, tracing systems, and error handlers to redact authorization headers and known credential fields. 5. Avoid including keys in prompt text, tool arguments visible to the model, telemetry, exception messages, or application logs. 6. Support immediate key revocation and rotation. Consider scoped credentials, usage alerts, and conservative rate or spending limits to reduce the impact of disclosure. 7. Treat previously used query-string keys as potentially logged and rotate them after migrating to header-based authentication.