In this guide
A secret is anything that proves your app or your server is allowed to do something: an API key, a password, a token, a database connection string. When you build by prompting, it is easy to paste a key into the chat to "make it work", and the tool may write it straight into a source file. This is not a character flaw; it is the fastest way to get a demo running. It just has to be cleaned up before release.
This is general guidance, not a security audit.
Why it matters
An app package can generally be unpacked and read. Anything inside the app, including a key written in the code, should be considered readable by anyone who downloads the app. A key in a public code repository is readable by anyone who finds the repository.
What happens then depends on the key: someone could run up costs on your account, read data, or send requests as you.
Where to look
Search the whole project (including hidden files) for:
- Words like
key,secret,token,password,apikey,Bearer. - Long random-looking strings.
- Files such as
.env, config files, and "example" files that contain real values. - Backend URLs that include a password or token.
- Your chat or prompt history: if you pasted a key there, it has left your machine.
- Version control history: a key deleted today can still be in an older commit.
Fix order
- Replace, don't just hide. If a key was ever in code you shared, in a public repository or in a prompt, make a new one in the provider's dashboard and disable the old one.
- Move the secret out of the app. The usual pattern: the app calls your own small server, and only the server holds the key. Ask your coding tool to explain this pattern for your setup, then verify the result yourself with the search above.
- Limit what a key can do. Many providers let you restrict a key to one app or a spending cap. Use it.
- Keep secret files out of version control with an ignore rule, and check the history.
- Rebuild and search again, this time inside the finished app package.
Some keys are meant to be public (for example identifiers for a map or analytics service). Check the provider's documentation to know which kind you have.
If a key has already shipped
- Make a new key and disable the old one first.
- Look at the provider's usage page for anything unexpected.
- Ship an app update that uses the new setup.
- If user data may have been involved, check which legal duties apply to you; this is not legal advice.
What not to promise
Do not tell users the app is "secure" or "audited" unless someone qualified has audited it. Say what you actually do: for example, "we do not store passwords" only if that is true.
Next step
Fresh eyes help. AppReviewX offers private, structured feedback from other developers, and you can ask a tester to try things a normal user would not. Try AppReviewX.
Related: Vibe coding hub, bugs testers find in AI-built apps, closed test for an AI-built app.