T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:18
- Finding
- Publicly Documented Shared API Credential<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:18` **Vulnerability Type**: Hardcoded shared credential **Risk Level**: Medium ### Vulnerable Code Snippet ```text JIUJIUMINDMAP_API_KEY=jiujiu-secret-key-123-456 ``` The documentation exposes `jiujiu-secret-key-123-456` as a default trial API key and instructs users to assign it to `JIUJIUMINDMAP_API_KEY`. ### Technical Analysis API credentials must not be embedded in publicly distributed skill packages or their documentation. Because every user receives the same value, the credential cannot provide reliable authentication or request attribution. The effective severity depends on whether a compatible API service accepts this documented credential and whether that service is reachable by an attacker. The repository does not contain the server implementation, so server reachability and accepted privileges cannot be confirmed from the audited files alone. ### Attack Path 1. An attacker obtains the skill package or reads its documentation. 2. The attacker extracts the documented API key. 3. The attacker identifies a service that accepts this shared credential. 4. The attacker supplies the value through the expected `x-api-key` header. 5. If the service still accepts the key, the attacker can issue requests with the same authorization assigned to legitimate trial users. ### Impact Assessment If accepted by a reachable service, the exposed key may allow unauthorized API requests, quota consumption, service abuse, and impersonation of legitimate users. All users sharing the key would be represented by the same credential, preventing meaningful per-user attribution and selective revocation. No administrative privileges or access beyond the API key's server-side authorization can be established from the audited client code. ]]>
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the shared credential from the documentation and all distributed artifacts. 2. Revoke or rotate `jiujiu-secret-key-123-456` wherever it is currently accepted. 3. Provision a unique credential for each user or installation through an authenticated enrollment process. 4. Store credentials only in a secret manager or protected environment variable; never provide a working default value. 5. Prefer scoped, short-lived tokens with expiration, revocation, and rate limits. 6. Add server-side monitoring to detect use of the exposed key and investigate historical abuse. 7. Update the documentation to use an unambiguously nonfunctional placeholder, such as `YOUR_API_KEY`. ]]>