Keep swap API secrets out of the browser

Place a secret swap API credential in a server-side component. A value bundled into browser JavaScript, including a build-time environment variable, is available to the person running that browser.

Make the proxy narrow

Accept a validated trade request with supported chains, assets, amount, recipient and execution mode. Choose the upstream host and path on the server. Do not offer a generic fetch-any-URL endpoint that forwards an authentication header to a caller-selected destination.

Apply request-size limits, bounded timeouts and per-client usage controls. Normalize errors before returning them. Keep provider keys separate from wallet signing: a noncustodial quote proxy ordinarily has no reason to receive a user's private key or seed phrase.

OWASP's secrets guidance covers lifecycle and access controls. In a swap backend, use separate credentials for development and production, restrict who can read them, and prevent them from entering crash reports or request logs.

Protect the caller as well

A secret backend does not make its returned transaction intrinsically trustworthy. The browser should still bind the response to the reviewed chain, account, tokens and amount. Server compromise or an upstream schema error can otherwise flow directly into a wallet prompt.

Set caching rules consciously. Wallet-specific payloads should not leak through shared caches. An indicative public price cache can use a different route and data policy.

Verification boundary

Inspect the built front-end bundle and browser network requests for service credentials. Test that a caller cannot supply an arbitrary upstream URL or override privileged headers. Verify that a simulated upstream failure produces a useful public error without returning the key. These checks protect the architecture; they do not require a real swap.