Why the API Keys in Your App Aren't Secret

By Marko, founder of UBI · October 22, 2026

If your website or app contains a powerful API key, that key isn't secret. Anyone who downloads your app or opens your site in a browser can find it with enough patience. An API key is the password-like code that lets your app use an outside service, such as a payment provider, an AI model or a database. One exception matters a lot. Some providers issue keys that are designed to be public, and those are fine in your front-end code. The rest belong on your server.

I learned to explain this more clearly during a conversation at Cloudflare Connect 2026 in San Francisco (October 19–21). I spent time at Approov's booth, mostly talking with Pearce Erensel, Approov's Global VP of Sales, and the Approov team. Approov sells security for mobile apps and the APIs behind them, so treat their framing as vendor material. The core idea still holds up, and it changed how I explain this to the non-technical founders I teach.

Here's the short version I posted on LinkedIn afterwards:

"Assume anyone can read your app's code."

The rest of this guide explains what that means, how keys actually get stolen, and what to ask your coding agent to change.

The Quick Answer: Is It Safe to Put an API Key in Front-End Code?

No, unless the provider explicitly says that key is safe to publish.

A privileged API key inside software you send to users should be treated as exposed. Browser code can be read. Mobile app files can be taken apart and their network traffic examined. And a request carrying your valid key only proves one thing: whoever sent it has the key. It doesn't prove the request came from your genuine app.

So keep privileged keys on a server you control. Limit what that server will do. Replace any key that was ever exposed.

A Valid Key Doesn't Prove a Request Came From Your App

This was Approov's central argument, and it's the bit most founders miss.

Approov puts it as authentication is not the same as trust. Authentication means "this request has the right credential." Trust means "this request came from my real, unmodified app, used the way I intended."

Think of a key to an office building. The door opens for anyone holding it. It can't tell your employee apart from someone who found the key on the pavement.

That's how most API keys work. The outside service checks the key and says yes. If someone copies your key into their own script, the service can't tell the difference. Your account pays the bill either way.

Two Ways Attackers Steal API Keys From Mobile Apps

How do hackers actually get keys out of an app? Approov describes two main routes.

1. Static Binary Analysis

A binary is the packaged app file you ship to the App Store or Google Play. Static binary analysis means taking that file apart without running it and searching it for text that looks like a key.

You don't need to be a genius to do this. Keys often have recognisable shapes, such as long strings with a predictable prefix. Search tools find them quickly.

Some developers hide keys in native code (on Android, that's code written with tools called JNI/NDK, which is harder to read than normal app code). Approov notes this makes reverse engineering the binary harder. But it won't stop the second method.

2. Man-in-the-Middle Interception

A man-in-the-middle (MitM) attack means sitting between the app and the server and reading the messages as they pass. Approov published a walkthrough called "Steal That API Key with a Man in the Middle Attack", first published in April 2019 and last updated in November 2021.

In it, they ran a demo currency-converter app on an Android emulator (a simulated phone on a computer). Then they routed its traffic through mitmproxy, a free tool for inspecting HTTPS traffic. The API key showed up in plain sight, sitting in the web address of each request as a URL parameter.

A few important caveats, because this gets exaggerated online:

• This isn't someone on the same café Wi-Fi reading your traffic. Normal HTTPS encrypts it in transit. The attacker in this demo controls the device and tells it to trust their interception certificate.
• That's exactly the point, though. An attacker who wants your key simply installs your app on a phone they control. Their own device, their rules.
• URL parameters add extra exposure. A key in the web address is encrypted in transit, but it can still turn up in server logs and anywhere the full address gets recorded.
• It's a demonstration, not a statistic. It shows the mechanism works. It doesn't tell you how often it happens.

Your Website Has the Same Problem

Everything above applies to websites too. It's arguably easier.

The front end of your site is the code a browser downloads and runs: the HTML, CSS and JavaScript. Every visitor gets a copy. Anyone can open the browser's developer tools (right-click, then "Inspect") and read it, including every network request the page makes.

So if your site calls an AI model straight from the browser using your key, that key is in the page. Or in the request. Usually both.

A private GitHub repository doesn't change this. Your source code might be private. The built site you deploy is public by design.

Why AI-Built Apps Are Especially Prone to This

Tools like Claude, Cursor and Lovable are brilliant at making something that works. And that's the trap. An app with a key in the front end works perfectly. Nothing breaks. No error appears.

The mistake only shows up later, as a surprising bill or someone else using your service. An app can function correctly while hiding a costly architectural decision.

There's a wider shift happening too. The same week as Cloudflare Connect, I came across PhotoCraft, a free open-source Photoshop alternative from the ArtCraft project. Its repository describes it as a clean-room reimplementation of Adobe Photoshop, built from public specifications and observed behaviour. To be clear, that isn't about stealing secrets or source code. But it shows how much software you can now study and rebuild just from what you can observe. Your shipped app is observable. Plan accordingly.

Some API Keys Are Designed to Be Public

Before you panic and rip everything out, here's the nuance. Not every key is a secret.

Many providers issue two kinds:

• Publishable keys (identifiers). These tell the service which account a request belongs to. They're meant for front-end code and can't do much damage on their own. Stripe's documentation, for example, separates publishable keys (safe in your website or app) from secret keys (which must stay on your server).
• Privileged secrets. These can spend money, read customer data, send emails or change settings. They must never reach a user's device.

The rule is simple: check the provider's documentation for each key. If it doesn't explicitly say "safe to publish," treat it as a secret.

Where to Store API Keys in an App You Built With AI

Here's the answer to the question I hear most. Store privileged keys on your server, and have your app ask your server to do the work.

The code that runs only on your server is never sent to anyone's browser or phone. That's the difference. Servers can still be misconfigured or breached, so this isn't magic. But it moves the secret out of every user's hands.

Exposed privileged credential:
User's app (contains the secret) → Outside service

Preferred arrangement:
User's app → Your server endpoint → Outside service
                    |
          Secret stays server-side

An endpoint is simply a specific address on your server that your app can call, like /api/translate.

What About Environment Variables?

You've probably been told to "put it in an environment variable." Good advice, but incomplete. What matters is where the value ends up.

A server-only environment variable keeps a secret out of client code. Yet some build tools copy certain variables straight into the JavaScript your visitors download. Vite's documentation, for instance, explains that variables with the VITE_ prefix are exposed to client-side code. So check the built app, not just the config file.

Keep Important Logic on the Server Too

The same thinking applies beyond keys. Prices, permissions and "has this person paid?" checks should be decided on your server. If the browser decides, the browser's user can change the answer. Ordinary interface logic, like how a menu opens, can stay in the front end.

Step-by-Step: How to Fix Exposed API Keys

You don't need to do this yourself. You need to know what to ask for and how to check it was done.

1. Inventory every key. Search source code, deployed site files, mobile app packages and the requests your app sends.
2. Classify each one. Publishable or privileged? Check the provider's docs.
3. Remove privileged secrets from anything delivered to browsers or devices.
4. Move those calls behind your own server endpoints.
5. Rotate every exposed key. Rotating means creating a new key and switching off the old one. Moving a key doesn't cancel copies already taken, sitting in old app versions or someone else's notes. If you suspect abuse, revoke first and fix after.
6. Check usage records in each provider's dashboard for anything unexpected.
7. Verify the live result and set up a recurring check so this doesn't creep back in.

Don't Turn Your Server Into an Open Proxy

This step gets skipped constantly. Once your key sits behind your endpoint, someone could just call your endpoint instead. Then they're spending your money with extra steps.

So your endpoint should:

• Only allow the specific actions your app needs
• Check who's calling, where your app has logged-in users
• Validate the input it receives
• Apply rate limits and usage caps
• Never let the caller choose arbitrary destinations or privileged operations

OWASP's REST security guidance covers these controls in more depth. Also note that browser CORS settings alone don't stop someone calling your endpoint directly from a script.

What to Ask Your Coding Agent to Check

Copy this into Claude, Cursor or whichever agent you use:

Review this application's source, build configuration, deployed frontend
assets, and available mobile bundles for exposed credentials.

For each finding, report:
- File or request location, with the credential value redacted.
- Provider and documented credential type.
- Whether it reaches a user's browser or device.
- Potential permissions and business impact.
- Recommended remediation and verification.

Distinguish explicitly publishable identifiers from privileged secrets.
Do not print full credentials in your report.

Move privileged service access behind narrowly scoped server endpoints.
Check authorization, input validation, allowed operations, rate limits,
and usage controls appropriate to the application.

Identify exposed credentials requiring replacement and revocation.
State any account access or deployment steps needed to complete this.

Verify the production build and report what you inspected, what changed,
what passed, and what remains unverified.

How to Know the Fix Actually Worked

Don't accept "all secure now" as an answer. Ask for evidence that:

• Privileged keys are absent from the live production files, not just the source code
• The features still work through your server
• Old keys have been revoked in each provider's dashboard
• Your endpoints refuse unauthorised or excessive use
• The report states what it checked and what it didn't

That last point matters. A report that names its limits is far more trustworthy than one claiming perfection.

What About Certificate Pinning and Obfuscation?

You may hear these suggested as fixes. They help, but they solve different problems.

• HTTPS protects traffic in transit.
• Obfuscation scrambles code to make reading it slower.
• Certificate pinning makes the app trust only one specific server certificate, which blocks many interception setups.

Approov argues in its "Man in the Middle Myths and Legends" piece that pinning can be bypassed, including with free third-party tools, on a device the attacker controls. Their recommendation is runtime checks that confirm a request comes from a genuine, unmodified app. That's also what they sell, so weigh it accordingly. Such checks add useful evidence about the client. They don't replace keeping secrets server-side or limiting what your endpoints allow.

Frequently Asked Questions

Does finding an API key in my front end mean I've been hacked?

No. First check whether the key is meant to be public. If it's a privileged secret, that's an exposure needing a fix, but it doesn't prove anyone used it. Look at the provider's usage records before drawing conclusions.

Can someone steal an API key from my mobile app?

Yes. They can search the app file for key-shaped text (static binary analysis) or watch its traffic on a device they control (man-in-the-middle interception). Hiding keys in native code slows the first method but doesn't stop the second.

Does HTTPS hide API keys from my app's users?

From strangers on the network, generally yes. From the person holding the device, no. They can configure their own phone to inspect the traffic.

Why replace a key after I've removed it?

Because removal only affects future versions. Copies already exist in old releases, caches and possibly someone else's hands. Only revoking the old key cancels them. OWASP's secrets management guidance covers rotation in detail.

Once the key is on my server, can people still run up my bill?

Yes, if your endpoint does whatever it's asked. Limit actions, validate input, and set rate limits and usage caps.

Can a website scan prove all my secrets are safe?

No. A public scan can only see what's public. It can't inspect your private code, mobile app files, provider settings or server rules. Any useful review should tell you exactly what it covered.

Key Takeaways

• Assume anyone can read your app's code. Anything shipped to a browser or phone can be inspected.
• A valid key proves possession, not that the request came from your real app.
• Publishable keys are fine in front-end code. Privileged secrets aren't.
• Store privileged keys on your server and have your app ask your server.
• Lock down your endpoints so they can't be abused as a proxy.
• Rotate any key that was ever exposed. Moving it isn't enough.
• Ask for evidence of the fix, including what wasn't checked.

Check the Rest of Your Site With UBI

Security reviews like the one above are a job for your coding agent, using the prompt in this guide. UBI's scan doesn't run security tests, and it won't find exposed keys.

What it does check is the rest of the technical picture that quietly holds sites back: SEO, AI search readiness, performance, accessibility, and how well AI agents can use your site. Think of it a bit like daycare for your website. You drop it off, it gets looked after, and you get on with running the business.

Run a free scan at ubi.studio. Just paste in your URL.

Related reading we're planning: front end vs back end for non-technical founders, how to keep third-party API costs under control, and a pre-launch checklist for AI-built apps.

Sources

• Steal That API Key with a Man in the Middle Attack – Approov - Vendor walkthrough of intercepting a demo Android app's traffic with mitmproxy to read an API key from a URL parameter; first published April 2019, updated November 2021
• Man in the Middle Myths and Legends – Approov - Vendor discussion of certificate pinning, its bypasses, and runtime app-integrity checks
• PhotoCraft repository – ArtCraft project on GitHub - The project's own description as a clean-room reimplementation of Photoshop built from public specs and observed behaviour
• API keys – Stripe Documentation - Distinction between publishable keys and secret keys
• Env Variables and Modes – Vite Documentation - How VITE_-prefixed variables are exposed to client-side code
• REST Security Cheat Sheet – OWASP - Guidance on API access control, input validation and rate limiting
• Secrets Management Cheat Sheet – OWASP - Guidance on storing, rotating and revoking secrets

Editor notes before publishing:

1. Approov article URL. Your notes use approov.io/steal-that-api-key-..., and the brief uses approov.io/blog/steal-that-api-key-.... I used the version from your notes. Please confirm which one resolves.
2. Names and dates. Confirm Pearce Erensel's title and the event dates.
3. Vice report. I left out the Vice report and the Claude Opus 5.5 detail, as the brief asked, because the original report hasn't been checked yet.
4. No invented details. I didn't add any anecdotes, quotes or figures beyond those in your notes and the cited sources.