T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:34
- Finding
- API Key Exposed Through URL Query Parameters## Vulnerability Details **File Location**: `SKILL.md:34`, `SKILL.md:79`, `SKILL.md:85`, `SKILL.md:91`, `SKILL.md:106`, `SKILL.md:114`, `SKILL.md:120`, `SKILL.md:128`, `SKILL.md:134`, `SKILL.md:140`, `SKILL.md:146`, `SKILL.md:152`, `SKILL.md:158`, `SKILL.md:166`, and `SKILL.md:179` **Vulnerability Type**: API credential disclosure through URL query parameters **Risk Level**: Medium ### Vulnerable Code Representative REST example from `SKILL.md:34`: ```bash curl "https://api.twelvedata.com/price?symbol=AAPL&apikey=${TWELVEDATA_API_KEY}" ``` The same pattern is repeated throughout the endpoint examples, including: ```bash curl "https://api.twelvedata.com/quote?symbol=AAPL&apikey=${TWELVEDATA_API_KEY}" ``` ```bash curl "https://api.twelvedata.com/time_series?symbol=AAPL&interval=1day&outputsize=100&apikey=${TWELVEDATA_API_KEY}" ``` The WebSocket example at `SKILL.md:179` also places the credential in the URL: ```text wss://ws.twelvedata.com/v1/quotes/price?apikey=YOUR_API_KEY ``` ### Technical Analysis Placing an API key in a URL query string unnecessarily increases its exposure. Although HTTPS protects the URL while it is in transit, the complete URL may still be recorded by application logs, reverse proxies, API gateways, monitoring and tracing systems, debugging tools, shell histories, process diagnostics, or error reports. The Skill already documents the safer REST authentication method at `SKILL.md:38-42`: ```bash curl -H "Authorization: apikey ${TWELVEDATA_API_KEY}" \ "https://api.twelvedata.com/price?symbol=AAPL" ``` Nevertheless, nearly all subsequent REST examples use query-string authentication. Users or agents following those examples are therefore encouraged to use the higher-exposure method even though a header-based method is available. The examples use environment-variable expansion rather than hardcoding a real credential, so no actual API key is committed to ...[truncated 1930 chars]
- Remediation
- ## Remediation Suggestions 1. Replace all REST query-string authentication examples with the documented authorization header: ```bash curl \ -H "Authorization: apikey ${TWELVEDATA_API_KEY}" \ "https://api.twelvedata.com/price?symbol=AAPL" ``` 2. Apply the same header-based pattern consistently to `/quote`, `/time_series`, `/symbol_search`, technical indicators, fundamentals, dividends, and batch requests. 3. For WebSocket connections, use a supported header, initial authentication message, or short-lived token mechanism if Twelve Data supports one. If URL authentication is the only supported mechanism, explicitly document that limitation and warn users not to log, print, retain, or share the connection URL. 4. Add credential-handling guidance: - Redact `apikey` values from request and error logs. - Disable verbose command tracing when secrets are expanded. - Avoid copying authenticated URLs into tickets, chat messages, or telemetry. - Rotate the API key immediately if an authenticated URL is exposed. - Restrict the key's permissions and quota where the provider supports such controls. 5. For `~/.openclaw/.env`, recommend restrictive file permissions and ensure the file is excluded from version control and diagnostic bundles. Avoid documenting duplicate plaintext storage in multiple configuration fields unless OpenClaw specifically requires it.