T09 · Insecure Skill Coding Practices
- Location
SKILL.md:224- Finding
API Key Exposed in WebSocket URL Query Parameter
- Content
View full analysis
`. 3. A local diagnostic system, reverse proxy, API gate ...[truncated 1282 chars]- Remediation
View remediation
``` 2. **Use short-lived connection tokens if headers are unsupported.** Add an authenticated HTTPS endpoint that exchanges the long-lived API key for a narrowly scoped, single-use WebSocket token with a short expiration period. 3. **Consider an authenticated WebSocket subprotocol.** If supported by the server and client ecosystem, transmit a temporary credential through a designated WebSocket subprotocol rather than the URL. 4. **Apply least privilege.** Scope WebSocket tokens to required channels, symbols, subscription tier, and connection duration. They should not authorize key management, billing changes, or unrelated API operations. 5. **Redact sensitive query parameters.** Configure clients, gateways, proxies, telemetry platforms, and server logs to redact `apiKey` and similar credential parameters. Avoid printing complete connection URLs in errors and diagnostics. 6. **Rotate potentially exposed keys.** Revoke and replace keys that may already have appeared in logs, shell history, traces, or monitoring systems. 7. **Update the Skill documentation.** Replace the credential-bearing example with the secure authentication mechanism and explicitly warn agents not to place long-lived API keys in URLs, command-line arguments, logs, or generated output. ]]>
