T09 · Insecure Skill Coding Practices
Warning
- Location
references/frontend-pattern.md:151- Finding
Client-Side Exposure of LLM Provider API Credentials
- Content
View full analysis
void, onDone: () => void, onError: (err: string) => void, ) { try { const res = await fetch(apiUrl, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${apiKey}` }, body: JSON.stringify({ model, messages, stream: true, temperature: 0.3, max_tokens: 600 }), }); ``` ### Technical Analysis The documented function is presented as a frontend streaming implementation and accepts a provider API key directly in browser-executed code. It then places that credential in the outbound `Authorization` header. Secrets used by browser code cannot be reliably protected from end users or compromised client-side execution contexts. The key can be recovered through browser developer tools, request inspection, JavaScript breakpoints, malicious extensions, cross-site scripting, or inspection of application state. The function also accepts an unrestricted `apiUrl`. Consequently, configuration errors or attacker influence over that value could cause both the bearer credential and the complete `messages` payload to be transmitted to an unintended server. The messages may contain medical, legal, financial, or confidential internal knowledge-base information. Network transmission is necessary for the Skill's remote LLM functionality, and no hardcoded malicious endpoint was identified. However, transmitting a long-lived provider credential from frontend code exceeds the minimum privilege required: the browser only needs authorization to use an application-controlled backend, not direct possession of the upstream prov ...[truncated 1453 chars]- Remediation
View remediation