Guide · 4 minute read · 21 October 2026

Is it safe to put API keys in my app?

Your app talks to other services, and each one gave you a key. Whether a key can sit in your app depends on what it gives access to. Some are made to be seen. Others work like a card number: whoever copies one can spend on your account.

sk_••••••

Anything in the browser can be read

A website's files are downloaded to every visitor's computer, and anyone can look at them. Right-click and choose View page source, or open the browser's developer tools and look at the files and the requests the page makes. A value inside a website's files can't be hidden from a curious visitor.

That includes settings. When your app uses a name that starts with VITE_, NEXT_PUBLIC_ or REACT_APP_, building the app copies the value into the downloaded files. That is what the prefix is for.

View page source
const config = {
  url: "https://api.example.com",
  apiKey: "sk_4f9a…",
};
A key inside the files a visitor downloads is one right-click away.

Keys made to be public

  • the Supabase anon or publishable key, as long as Row Level Security is on for every table
  • the Firebase web config (the block with apiKey, authDomain and projectId), as long as Security Rules are set
  • the Stripe publishable key, which starts with pk_
  • a Google Maps key, once you've limited it to your own web address in the Google Cloud console

These services expect the key to be seen. The protection is in the rules you set on their side.

Keys that must never be in the browser

  • keys for AI services: anyone who copies one can run requests on your account, and you get the bill
  • the Stripe secret key, which starts with sk_
  • the Supabase service_role key, which ignores every access rule
  • database passwords and connection strings, such as the value of DATABASE_URL
  • keys for sending email or text messages, which can be used to send spam in your name

A quick test: if the key lets someone spend money or read other people's data, it has to stay on a server.

When a key leaks

There are programs that read public code all day looking for keys, on GitHub especially. A key pushed to a public repository can be found and used before you notice it's there. Deleting the file afterwards doesn't help much, because the key may already be copied. What stops it is replacing the key.

Fixing a key that's in the wrong place

  1. Make a new key in the service's dashboard and delete the old one. Deleting it is what stops the copies working.
  2. Move the code that uses the key to a server, or to a small function your host or database runs for you. The browser then asks that function, and the key never reaches the browser.
  3. Set a spending limit or a usage alert on the service, if it has one.
  4. If you use Supabase or Firebase, check that the access rules are on for every table or collection.

Your AI tool can do the moving. Paste this in:

“List every API key and secret this app uses. For each one, tell me whether it ends up in the files the browser downloads, whether it's meant to be public, and how to move the private ones to the server side.”

BrowserNever sees the key
Asks
sk_••••Your functionHolds the key
Calls
The serviceBills your account
Move the call to a function that runs on a server. The browser asks the function; only the function knows the key.

Keep keys out of public code

Secrets usually live in a file called .env. Before the project goes to a public GitHub repository, check that .env is listed in the file called .gitignore, so it stays on your computer. Give the values to your host as settings, where they're kept apart from the files visitors download.