Keep the LLM API key on your server. A key placed in a mobile app, a browser bundle or a public config file can be pulled out by anyone who uses the app, and the key pays for every request made with it. Put a thin backend in front, authenticate your own users, and call the provider from there.
Why obfuscation does not help
Teams often try to hide the key: split the string, encode it, fetch it at startup. None of this changes the core fact. The app has to send the key with each request, so the key is visible to anyone who can watch the traffic from their own device. A proxy tool on a laptop is enough.
The same goes for browser code. Environment variables that a build tool inlines into the bundle are public the moment the page loads. Many frameworks make this easy to do by accident, because a prefix on the variable name marks it as safe to expose.
What an attacker does with a leaked key
A leaked LLM key is not a data breach by itself. It is a bill. Someone else runs their own workload on your account until you notice, hit a spend limit or revoke the key. The OWASP page on unbounded consumption calls this pattern Denial of Wallet: large volumes of pay-per-use operations that create unsustainable cost for the provider of the app.
There is a second cost. If the key is tied to a project with fine-tuned models, uploaded files or stored conversations, a broad key may reach those too. Scope matters, which is covered in the post on separating keys per environment and feature.
What to build instead
The pattern is simple and boring, which is the point.
- The app signs the user in with your normal login.
- The app calls your backend endpoint, for example a chat route, with the user's session token.
- The backend checks who the user is, applies limits, and then calls the provider with the key it holds.
- The backend returns only what the app needs.
Step three is where the value is. The server can cap input size, set a maximum output length, pick the model, and refuse requests that look wrong. The client never chooses the model name or the system prompt. If the client could, an attacker could ask for your most expensive model with a huge output limit.
Edge cases people ask about
Some providers offer short-lived tokens for realtime or voice sessions, minted by your server and handed to the client. That is a different design: the long-lived key stays on the server and the client gets a credential that expires quickly. If you use that, check the provider's documentation for what the token can do and how long it lives, and still apply per-user limits when you mint it.
Prototypes and hackathon demos are the usual place keys leak. A demo with a key in the page is fine for an afternoon on a throwaway account with a tiny spend limit. It is not fine once real users arrive.
If a key has already shipped
Treat it as leaked. Revoke it, issue a new one to the server only, set a monthly spend limit below what you can afford to lose, and check the usage page for the days it was live. The steps are in how to rotate leaked API keys. Old app versions will break when the key is revoked, which is the right outcome.
Safeguard's secret and dependency scanning can flag keys committed to repositories, and the free scan at https://gold.safeguard.sh/scan is a quick place to start.
Quick check
Can I restrict a key to my app's domain and call it from the browser?
Domain restrictions are easy to spoof outside a browser, since the restriction is only a header the caller sets. Do not rely on it for a key that can spend money. Use a server.
Is a key in a private mobile app repo safe?
No. The repo is private, but the compiled app is distributed to every user, and the key travels with it.
Sources
Last reviewed: 19 October 2026.
