T09 · Insecure Skill Coding Practices
Warning
- Location
- EXAMPLES.md:354
- Finding
- Inbox API Key Exposed in a Dashboard URL Query String<![CDATA[ ## Vulnerability Details **File Location**: `EXAMPLES.md:354` **Vulnerability Type**: Sensitive credential exposure through a URL query string **Risk Level**: Medium ### Vulnerable Code ```javascript return { email: account.email, received: inbox.emails?.[0] || null, viewUrl: `https://botemail.ai/dashboard?email=${account.email}&key=${account.apiKey}` }; ``` ### Technical Analysis The example embeds the account API key directly in the `key` query parameter of a dashboard URL. Although the URL uses HTTPS, query parameters may still be retained or disclosed through: - Browser history and synchronized browsing data - Server, reverse-proxy, CDN, and application access logs - Monitoring and analytics systems - Screenshots, copied links, bookmarks, and support records - Referrer headers when the dashboard loads external resources or follows links - Local application telemetry The API key is used elsewhere as a bearer credential for authenticated inbox operations. Consequently, possession of the key may provide access to messages received by the associated bot address. These messages can include verification links, account confirmation tokens, or 2FA codes. Credential transmission in an `Authorization` header to the declared BotEmail API is necessary for authenticated inbox access. Embedding that credential in a dashboard URL is not necessary and exceeds secure minimum disclosure. ### Attack Path 1. A user follows the email-template testing example. 2. The function returns a dashboard URL containing both the inbox address and API key. 3. The user opens, copies, logs, bookmarks, or otherwise handles that URL. 4. A browser synchronization service, access log, analytics platform, external resource, or person with access to the URL obtains the query string. 5. The attacker extracts the `key` value. 6. The attacker submits the exposed value as a bearer credential to the BotEmail inbox API. 7. Subject to the API key's server-side permissions, the a ...[truncated 831 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the API key from all URL paths and query parameters. 2. Authenticate dashboard access through a secure server-side session established after explicit login. 3. If a credential must be submitted to initialize a session, use a non-persistent POST body and immediately exchange it for a short-lived, scoped session cookie. 4. Configure session cookies with `Secure`, `HttpOnly`, and an appropriate `SameSite` policy. 5. Do not store bearer credentials in browser history, local storage, analytics events, logs, or referrer-visible URLs. 6. Configure a restrictive `Referrer-Policy`, such as `no-referrer`, as defense in depth. 7. Use short-lived, dashboard-only access tokens if shareable dashboard links are required. Such tokens should be single-use or narrowly scoped and must not be reusable against the inbox API. 8. Redact credential-bearing values from application, proxy, CDN, and monitoring logs. 9. Rotate any API keys that may already have been exposed through generated dashboard URLs. 10. Replace the vulnerable return value with a credential-free dashboard URL, for example: ```javascript return { email: account.email, received: inbox.emails?.[0] || null, viewUrl: 'https://botemail.ai/dashboard' }; ``` ]]>
