T09 · Insecure Skill Coding Practices
Warning
- Location
- lib/api_client.py:31
- Finding
- Trading Credentials Are Unnecessarily Sent to Public Analytics Endpoints<![CDATA[ ## Vulnerability Details **File Location**: `lib/api_client.py:31-38` **Vulnerability Type**: Violation of least privilege through unnecessary credential transmission **Risk Level**: Medium ### Vulnerable Code ```python # Public API requires authentication — sign with PTK key if available config = _load_config() if config.get("api_key") and config.get("api_secret"): path = f"/api/public{endpoint}" auth_headers = _sign(config["api_secret"], "GET", path) req.add_header("X-PTK-Key", config["api_key"]) for k, v in auth_headers.items(): req.add_header(k, v) ``` This behavior conflicts with the declaration in `README.md:99` that the Public Analytics API requires no authentication: ```markdown - **Public Analytics API** (no auth): [api.prob.trade/api/public](https://api.prob.trade/api/public/overview) — markets, stats, traders ``` ### Technical Analysis Every analytics request made through `fetch()` loads the configured API credentials. If both values are present, the client sends the API key in the `X-PTK-Key` header and an HMAC authentication proof in the `X-PTK-Signature` header. The API secret itself is not transmitted. It is used locally to generate an HMAC-SHA256 signature, and requests are restricted to the fixed HTTPS host `api.prob.trade`. Consequently, this is not evidence of deliberate secret exfiltration. However, the project documentation identifies these analytics endpoints as public and unauthenticated. Sending credentials on these requests therefore exceeds the minimum privileges required for analytics functionality. It exposes the API key and signed authentication material to additional endpoint handlers, server logs, monitoring infrastructure, TLS-inspection systems, and any compromised component servicing public analytics requests. Whether a captured signature can be replayed depends on server-side timestamp validation, replay prevention, and the scope assigned to the API key. ...[truncated 1431 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not load or attach credentials in `fetch()` when public analytics endpoints are genuinely unauthenticated. 2. Restrict credential handling to `trading_request()` and other endpoints that explicitly require authentication. 3. If analytics authentication is mandatory, correct all conflicting documentation and use a separate read-only analytics credential without trading authority. 4. Scope trading keys to the minimum supported permissions and prevent them from being accepted by unrelated public endpoint handlers. 5. Enforce short signature-validity windows and server-side replay prevention, such as nonce tracking. 6. Ensure API gateways, proxies, and application logs redact `X-PTK-Key`, `X-PTK-Signature`, and `X-PTK-Timestamp`. 7. Document exactly which authentication fields leave the machine and which endpoint classes receive them. ]]>