T09 · Insecure Skill Coding Practices
Error
- Location
- references/api-templates.md:44
- Finding
- Partner API Key Sent to an Unrestricted Runtime-Configured Destination## Vulnerability Details **File Location**: `references/api-templates.md`, lines 44-50 **Vulnerability Type**: Unrestricted credential destination **Risk Level**: High **Complete Code Snippet**: ```ts async function brekRequest(path: string, init?: RequestInit) { const response = await fetch(`${BREK_BASE_URL}${path}`, { ...init, headers: { 'content-type': 'application/json', 'x-partner-api-key': BREK_PARTNER_API_KEY, ...(init?.headers || {}) } }); ``` ### Technical Analysis The transport wrapper automatically sends `BREK_PARTNER_API_KEY` to the origin specified by `BREK_BASE_URL`. Although transmitting a credential is necessary to authenticate to the Brek API, the Skill does not require validation of the URL's scheme, hostname, port, embedded credentials, or resolved network address. Because `BREK_BASE_URL` is a required runtime value rather than a fixed or allowlisted Brek endpoint, anyone capable of influencing deployment configuration can redirect authenticated requests to an attacker-controlled destination. This exceeds the minimum network privilege needed for the declared integration. The wrapper also does not define a redirect policy. Depending on the runtime's `fetch` behavior, redirects may create additional unintended network exposure. Furthermore, spreading `init.headers` after the default headers permits callers to override authentication and content-type headers. That is not the primary credential-disclosure path, but it weakens the wrapper's security invariants. ### Attack Path 1. An attacker gains influence over the environment or runtime configuration supplying `BREK_BASE_URL`. 2. The attacker changes it to an HTTP or HTTPS server under their control. 3. A user invokes a normal hotel-search, booking, or payment-confirmation flow. 4. `brekRequest` constructs the destination from the attacker-controlled base URL. 5. The wrapper sends `BREK_PARTNER_API_KEY` an ...[truncated 884 chars]
- Remediation
- ## Remediation Suggestions 1. Use a fixed official Brek API origin in production instead of accepting an arbitrary runtime base URL. 2. If configurability is required, parse the value with a standard URL parser and enforce: - The `https:` scheme. - An exact allowlist of approved Brek hostnames. - The expected port. - No username or password in the URL. - No fragments or unexpected base paths. - Rejection of localhost, IP literals, private networks, link-local addresses, and cloud metadata addresses. 3. Resolve endpoint paths with `new URL(path, approvedBaseUrl)` and verify that the resulting origin remains identical to the approved origin. 4. Disable redirects or validate every redirect target before following it. 5. Prevent `init.headers` from overriding security-critical headers. Merge caller headers first, then set the validated authentication header explicitly. 6. Scope the API key to the minimum required tenant and API operations, rotate it periodically, and immediately rotate it after suspected exposure. 7. Ensure authorization headers, API-key headers, and request bodies containing sensitive identifiers are redacted from logs. 8. Add automated tests proving that unapproved schemes, hosts, ports, redirects, and private network destinations are rejected before credentials are attached.