API keys and secrets: how to keep them out of your code

How do you keep API keys and secrets safe in your app?

The short answer: API keys and secrets live on the server and nowhere else. You do not paste them into code files, you do not ship them to the browser, and you do not bundle them inside an iOS or Android app. They sit in environment variables or a dedicated secrets store, the backend reads them at runtime, and every call to a sensitive outside service goes through your server.

Why should a business owner care, not just the developer? Because a secret key works like a bank card with its PIN written on it. Whoever gets your payment gateway key may be able to issue refunds or see your customers' transactions. Whoever gets your AI model key can run thousands of requests on your account. Leaks are usually invisible until the bill arrives.

Building with AI makes the risk closer than it used to be. You paste a key into the chat so the integration works quickly, and the model drops it straight into a file that ships to the browser. This guide covers the kinds of secrets you have, where to keep them, how to check your app, and what to do on the day a key leaks. It is one part of the wider security checklist for AI-built apps.

Anything that reaches the user's device can be read by the user. A secret that reaches the browser is no longer a secret.

What secrets does your app actually have?

Start by knowing what you are protecting. Most small apps hold five to ten secrets, some added quietly while wiring up a service.

Where do secrets usually leak?

Keys rarely leak through some sophisticated hack. Most of the time they walk out through very ordinary places:

• Frontend code: a key written into a JavaScript file that every visitor downloads and can read with the browser's developer tools.
• Inside the mobile app: a published app package can be unpacked, so any key inside it can be extracted.
• On GitHub: a key went into an old commit and was later deleted, but it is still in the repository history. Public repositories are scanned automatically by many parties.
• In chats and groups: a key sent over WhatsApp to a freelancer or visible in a screenshot.
• In logs: code that prints the full request, headers included, so the key ends up in a log several people can read.
• In error pages: an error screen that shows server settings to the visitor.

The right pattern: environment variables and server-side calls

The safe pattern is simple: the frontend asks your server, and your server talks to the payment gateway or the AI model using the secret key. The user never sees the key, and on the server you can check who the user is, what they are allowed to do, and how many requests they have made before passing anything on.

1. 1
   List your secrets

   Write down every service connected to your app, which key type it uses, and who can access it.

2. 2
   Move them to environment variables

   Each secret is stored in the hosting settings under a clear name and read by backend code only.

3. 3
   Separate environments

   Sandbox keys in staging, live keys in production only. See staging vs production.

4. 4
   Restrict every key

   Use the narrowest permissions, restrict by domain or IP address where the service allows it, and set a monthly spending cap on AI keys.

5. 5
   Verify signatures

   Every payment webhook has its signature checked with the signing secret before an order is marked as paid.

On Fanann hosting, secrets are stored in the project settings on the server, and the agent calls payment and AI services from backend code by default. Reviewing the result before launch is still your job.

What if you are building with AI?

AI builders save a lot of time, but they sometimes do exactly what you say. If you paste a key into the chat and write 'connect payments with this key', the model may put it wherever works fastest, which is not always the safest place. The fix is to ask for the safe pattern explicitly, then check it.

Then check it yourself: open the app in your browser, open developer tools, and search the loaded files for the first characters of your secret key. If it shows up, something is wrong. For more on reviewing what the AI writes, read is AI-generated code secure?.

A key leaked? The five-step response plan

Leaks happen to professional teams too. What matters is how fast you act:

1. Revoke the key immediately in the service dashboard (revoke or roll). Do not wait to find out whether it was used.
2. Issue a new key, put it in your environment variables, redeploy, and confirm the service works.
3. Review logs and bills: odd payments or refunds, unusual AI usage, messages sent from your account.
4. Close the source of the leak: remove the key from the code, make a public repository private, and remove access for anyone who does not need it.
5. Record it and notify when required: if the leak may have exposed customers' personal data, check your obligations under the data protection law that applies to you.

Secrets checklist before launch

• No secret key anywhere in the frontend files or the mobile app.
• Every secret in environment variables, with clear names and a list of who can see them.
• Test keys are separate, and live keys are only used in production.
• Every AI key has a spending cap and an alert.
• The payment webhook signature is verified before any order is confirmed.
• The repository is private, its history has no keys, and the local settings file is excluded from Git.
• When a freelancer's engagement ends, rotate the keys they saw.
• The leak plan is written down and at least two people know it.

If you connect many outside services, also read connect your app to other services with APIs and webhooks, and for payments specifically, payment security basics and 3D Secure. Your practical next step: block one hour this week to list your secrets and work through the checklist above.

Frequently asked questions

Terms in this article