T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:42
- Finding
- API Credential Exposure Through URL Query Parameters<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:42`, `SKILL.md:70`, and `SKILL.md:125-126` **Vulnerability Type**: API credential disclosure through query-string transmission **Risk Level**: Medium ### Vulnerable Code Snippet ```text https://api.wuyinkeji.com/api/async/detail?key=【your API key】&id={task_id} ``` The same polling URL appears at lines 42 and 70. Lines 125-126 additionally instruct users that submission keys may be placed in URL parameters and that polling keys must be placed in URL parameters. ### Technical Analysis The skill explicitly requires the shared API credential to be included in the polling endpoint's query string. Query strings are commonly captured in HTTP access logs, reverse-proxy logs, monitoring platforms, browser or client histories, exception reports, and debugging telemetry. Although HTTPS protects the URL while it is transmitted over the network, it does not prevent the complete URL from being recorded at either endpoint or by authorized infrastructure components. The document already specifies an `Authorization` header for the polling request. Repeating the credential in the URL therefore expands its exposure without providing a necessary security benefit. The displayed credential is a placeholder rather than a live secret, but following these instructions with a real credential would create the vulnerability. ### Attack Path 1. An operator configures the skill with a valid API credential. 2. The agent constructs a polling request containing that credential in the `key` query parameter. 3. A client, reverse proxy, API gateway, monitoring service, or application server records the complete request URL. 4. A user with access to those records, or an attacker who compromises the relevant logging system, extracts the credential. 5. The exposed credential is reused against the image-generation API until it is revoked or expires. This exploitation path depends on an attacker obtaining access to a system that r ...[truncated 491 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the `key` parameter from every request URL, including both polling examples. 2. Transmit the credential exclusively in an HTTPS request header, preferably using a standard scheme such as: ```http Authorization: Bearer ${NANABANANA_API_KEY} ``` 3. Do not duplicate the credential in the JSON request body unless the external API strictly requires it. 4. Load the credential from a protected environment variable or secret manager rather than embedding it in the skill document or generated commands. 5. Configure clients, proxies, API gateways, and monitoring systems to redact `Authorization`, `key`, token, and credential fields. 6. Apply least privilege, usage limits, expiration, and rotation policies to the credential. 7. Rotate any real credential that has previously been transmitted in a query string and review relevant logs for unauthorized use. 8. If the provider cannot support header-only authentication, use a short-lived scoped token and ensure all infrastructure redacts the query parameter before logging. ]]>