T09 · Insecure Skill Coding Practices
Warning
- Location
references/api.md:274- Finding
Hardcoded OAuth Client Credential in API Documentation
- Content
View full analysis
&password= ``` The embedded Base64 value decodes to: ```text gFjHtJpa:C9fogwrjDWORT2GY ``` ### Technical Analysis The API reference distributes a static OAuth client identifier and secret in an HTTP Basic Authorization value. Base64 encoding provides no confidentiality, so anyone who can access the Skill package can recover and reuse the credential. The CLI implementation does not execute this cloud authentication flow, and the documentation labels it as reference-only. Nevertheless, including a live reusable credential in distributed Skill content violates secure secret-management practices. It also encourages use of the OAuth resource-owner password grant, under which users submit their account passwords directly to the token endpoint. This is not evidence of an obfuscated executable payload; it is an exposed authentication credential in documentation. ### Attack Path 1. An attacker downloads or otherwise obtains the Skill package. 2. The attacker reads `references/api.md` and extracts the documented Basic Authorization value. 3. The attacker Base64-decodes the value to recover the OAuth client identifier and secret. 4. The attacker sends requests to the documented `/oauth/token` endpoint using the exposed client identity. 5. If the attacker also possesses valid user credentials, they may request an access token and access cloud resources permitted to that user. The exposed client credential may also facilitate automated password testing unless the service applies effective rate limiting and abuse controls. ...[truncated 632 chars]- Remediation
View remediation
``` 4. Avoid distributing confidential OAuth client secrets in Skills, source code, examples, or client-side applications. 5. Prefer an officially supported public-client flow, such as Authorization Code with PKCE, rather than the resource-owner password grant. 6. If a confidential client is unavoidable, keep its secret in a controlled server-side secret manager and never expose it to the Agent or end user. 7. Apply token-endpoint rate limiting, client monitoring, anomaly detection, and credential-stuffing protections. 8. Review authorization-server logs for suspicious use of the exposed client identity and invalidate tokens obtained through unauthorized activity. ]]>