T09 · Insecure Skill Coding Practices
Warning
- Location
- references/overview.md:219
- Finding
- API Key Exposure Through URL Query Parameters and Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `references/overview.md`, lines 219–243 **Vulnerability Type**: Insecure credential handling **Risk Level**: Medium ### Vulnerable Code ```bash curl -X GET https://api.covalenthq.com/v1/eth-mainnet/address/demo.eth/balances_v2/ \ -u YOUR_API_KEY_HERE: \ -H 'Content-Type: application/json' ``` ```bash curl -X GET https://api.covalenthq.com/v1/eth-mainnet/address/demo.eth/balances_v2/ \ -H 'Authorization: Bearer YOUR_API_KEY_HERE' ``` ```bash curl -X GET "https://api.covalenthq.com/v1/eth-mainnet/address/demo.eth/balances_v2/?key=YOUR_API_KEY_HERE" ``` ### Technical Analysis The documentation presents authentication examples that encourage users to substitute a real API key directly into a URL or command-line argument. Placing an API key in the `key` query parameter is particularly unsafe because complete URLs are commonly retained by: - Reverse proxies and HTTP access logs - Application performance monitoring systems - Browser history and bookmarks - Terminal output, shell history, and copied diagnostic reports - Analytics, tracing, and network-observability platforms - Referrer headers in some navigation scenarios Although HTTPS protects the request in transit, it does not prevent the URL from being recorded at either endpoint or by local tooling. The document later discourages query-string authentication, but the actionable example remains available for users and agents to copy. Embedding an API key directly in a `curl` command can also expose it through shell history, terminal session recording, CI job logs, debugging output, and—depending on the operating system and process isolation—process argument inspection. This behavior exceeds minimum necessary credential exposure because the Skill only needs to authenticate requests to the declared GoldRush API; it does not need to place secrets in URLs or durable command history. Related command-line credential examples also appear in: ...[truncated 1496 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the query-parameter authentication example entirely. Do not support or demonstrate URLs containing `?key=...`. 2. Recommend the HTTPS `Authorization: Bearer` header as the sole REST authentication method. 3. Do not encourage users to place literal credentials directly in reusable commands or source files. 4. For application code, load the key at runtime from a protected environment variable or secret manager and ensure it is never committed to source control. 5. For interactive command-line testing, use a protected credential file, secret-manager integration, or non-persistent prompt mechanism that avoids storing the key in shell history. Apply restrictive file permissions where a temporary configuration file is unavoidable. 6. Configure applications, proxies, CI systems, and observability tools to redact: - `Authorization` headers - `key` query parameters - API-key prefixes such as `cqt_` and `ckey_` 7. Add an explicit warning that API keys must not be included in URLs, logs, screenshots, support tickets, or copied terminal output. 8. Rotate any key that has already been used in a query string, committed to source control, or exposed in command history or logs. 9. Update related examples in `SKILL.md` and `references/integration-guide.md` to follow the same protected credential-handling guidance. ]]>