T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:15
- Finding
- Hard-Coded Dify API Key## Vulnerability Details **File Location**: `SKILL.md`, line 15 **Vulnerability Type**: Hard-coded API credential **Risk Level**: High **Vulnerable Code Snippet**: ```markdown | api_key | string | Yes | app-pYPzawyEGIiagRmb1IhJv4PA | Dify application API key (obtained from the Dify console) | ``` ### Technical Analysis The skill documentation embeds a credential-like Dify application API key as the default value of the `api_key` configuration parameter. Secrets committed to project files can be recovered by anyone with access to the package, repository, distributed archive, logs, caches, or historical revisions. The file does not identify this value as an inert example, so it must be treated as a potentially active credential. Successful exploitation additionally requires access to or identification of the corresponding Dify API endpoint. The documented default endpoint is `http://localhost/v1`, but the reviewed project contains no implementation or deployment configuration proving where the key is accepted. ### Attack Path 1. An attacker obtains the distributed skill package or repository contents. 2. The attacker reads `SKILL.md` and extracts the embedded API key. 3. The attacker identifies, discovers, or already knows the Dify deployment associated with the key. 4. The attacker submits authenticated requests using the exposed key. 5. If the key remains active and the endpoint is reachable, the attacker can invoke operations permitted to the associated Dify application. ### Impact Assessment Exploitation could allow unauthorized use of the associated Dify application, consumption of service quotas, and access to application responses. Depending on the Dify application's configuration and the permissions attached to the key, submitted code, private knowledge-base-derived output, or other application data may be exposed. The key does not by itself demonstrate operating-system access, administrative privileg ...[truncated 156 chars]
- Remediation
- ## Remediation Suggestions 1. Immediately revoke and rotate the exposed API key in the Dify administration console. 2. Replace the committed value with a clearly nonfunctional placeholder such as `${DIFY_API_KEY}`. 3. Load the credential at runtime from a protected environment variable or dedicated secret-management service. 4. Ensure documentation, examples, logs, generated packages, and configuration templates never contain real credentials. 5. Review repository history and distributed artifacts for prior exposure; remove the secret from history where practical, while recognizing that history rewriting does not replace rotation. 6. Restrict the replacement key to the minimum required permissions, apply usage limits where supported, and limit network access to trusted clients. 7. Review Dify access and usage logs for suspicious requests made with the exposed credential. 8. Add automated secret scanning to development and release workflows to prevent recurrence.