T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:31
- Finding
- Bearer Credential Exposure Through URL Query Parameters and API Responses<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 31-37 and 41-45 **Vulnerability Type**: Authentication credential exposure **Risk Level**: High ### Vulnerable Code ```text **With query param (web_fetch — no custom headers needed):** ``` web_fetch: https://agentfuel.dev/v1/balance?key=YOUR_AF_KEY ``` Returns: `{ "credits": 12500, "key": "af_..." }` ``` ```text **With query param (web_fetch):** Use `web_fetch` with POST isn't supported — use the invoice endpoint via query param: ``` web_fetch: https://agentfuel.dev/v1/invoice?key=YOUR_AF_KEY&amount_usd=10 ``` ``` ### Technical Analysis The Skill explicitly recommends passing `AGENTFUEL_KEY`, a bearer credential controlling paid API credits, in URL query parameters. Query strings are frequently recorded by client histories, tool-call transcripts, proxy and server access logs, monitoring platforms, analytics systems, and error reports. HTTPS protects the URL while it is in transit but does not prevent disclosure through these endpoint and intermediary records. The documented balance response also returns the key in its response body. This unnecessarily reproduces the credential in agent output, execution logs, and conversation history. Possession of the key appears sufficient to authenticate paid API requests and credit transfers; therefore, any exposed copy functions as a reusable bearer token. This behavior is unnecessary for the declared gateway functionality because the Skill already documents authentication through the `Authorization: Bearer` header. Recommending query authentication solely because a particular tool cannot set headers weakens credential handling beyond minimum necessary privileges. ### Attack Path 1. A user follows the documented `web_fetch` example and substitutes a valid `af_` credential into the URL. 2. The complete URL is retained in tool history, agent transcripts, proxy logs, server access logs, telemetry, or an error report. 3. Alternatively, the balan ...[truncated 1232 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove all examples that place `AGENTFUEL_KEY` in a URL query parameter. 2. Require authentication exclusively through the HTTP `Authorization: Bearer` header. 3. If `web_fetch` cannot set custom headers, explicitly state that it is unsupported for authenticated endpoints rather than providing a less secure workaround. 4. Change the balance response so it never returns the complete credential. Omit the key or return only a safely masked identifier, such as `af_…last4`. 5. Configure the gateway, reverse proxies, monitoring systems, and analytics tools to redact authorization headers and credential-shaped values. 6. Reject or deprecate query-string authentication server-side after a migration period. 7. Rotate any key previously used in a query-string URL or exposed in endpoint output. 8. Add explicit documentation warning users not to include credentials, private data, or regulated information in logged URLs or prompts. 9. Apply narrowly scoped keys, spending limits, transfer restrictions, and revocation controls to reduce the impact of future disclosure. ]]>