The problem
A leaked API key is a credential that becomes visible somewhere it should not be: a browser bundle, mobile app binary, public GitHub repo, frontend config file, build artifact, or support screenshot. For AI-built apps, this often happens because the generated code is focused on making the feature work, not on separating public configuration from private credentials.
Founders may not notice the issue because the app still works. A payment provider charges cards, an AI API returns responses, a maps API loads, or an admin dashboard connects to a database. The danger is that the same key may also be available to anyone who knows how to inspect network calls, source maps, public repositories, or shipped app files.
Common causes
- Putting private API keys in frontend JavaScript, React components, or mobile source files.
- Using environment variables with public prefixes when the key should only exist on the server.
- Copying examples from documentation without understanding which keys are safe to expose.
- Committing `.env` files, service account files, private tokens, or test credentials to GitHub.
- Letting AI generate direct browser-to-provider calls that should go through a server endpoint.
Consequences
Exposed keys can lead to unexpected API bills, data access, account abuse, spam, quota exhaustion, and account suspension. Even when a key has limited permissions, it can reveal how your app is structured and give attackers a path to test other weaknesses. If the key belongs to a database, auth provider, AI service, email tool, or cloud account, the risk can move from annoying to business-critical very quickly.
How to identify exposed keys
Start by searching your repository for words like `api_key`, `secret`, `token`, `private`, `sk-`, `bearer`, and provider-specific prefixes. Inspect your deployed frontend bundle and browser network requests. Check whether source maps are public. Review mobile app configuration files and build settings. Confirm that private calls flow through server-side routes where credentials stay in environment variables that never ship to the client.
Then rotate anything suspicious. Rotation is not optional: once a credential has been committed publicly or shipped to users, you should assume it may have been copied.
How SouthStack can help
SouthStack reviews AI-built apps for secret exposure, client/server boundary mistakes, unsafe provider usage, environment variable handling, and repository hygiene. The audit focuses on practical fixes: what to rotate, what to move server-side, what permissions to reduce, and what launch checks should become part of your workflow.