Security Vulnerability: Private API Key Exposure in Client-Side Requests

[Argeare5]

Hello Enso Team,

While integrating the shortcuts-widget, I identified a significant security concern regarding how the widget handles authentication. Currently, the implementation requires the API key to be passed directly to the client-side provider. This results in the Private API Key being exposed in plain text within request headers (Authorization: Bearer <API_KEY>), easily accessible via the browser's Network tab.

Impact Analysis

Exposing a secret API key on the frontend introduces several risks that are blockers for any production-grade application:

1. Key Theft & Misuse: Any user can extract the key and use it to make unauthorized requests to the Enso API outside of the widget's context.
2. Quota Exhaustion: Malicious actors can use the stolen key to exhaust API rate limits, leading to Denial of Service (DoS) for the legitimate application.
3. Future Security Risks: While current API permissions might be limited, any future expansion of API capabilities (e.g., access to sensitive data or account-level actions) would immediately become a major vulnerability if the key is already compromised.

Current Implementation vs. Production Requirements

The current documentation enforces a pattern that forces developers to choose between using the widget and maintaining basic security hygiene. For a professional DeFi ecosystem, exposing credentials is not a viable trade-off.

Suggested Improvements

To align with security best practices and "Pure Web3" principles (technical integrity and self-custody), I suggest the following:

• Support for Backend Proxying: Update the widget/SDK to allow routing requests through a developer-owned backend proxy. This allows the API key to remain strictly server-side.
• Scoped/Public Keys: Implement a system of "Public Keys" restricted by domain (CORS) or specific low-risk scopes, intended specifically for frontend usage.
• Documentation Update: Explicitly warn against using the primary API key in client-side code and provide a recommended architecture for secure integration.

Evidence: