You built your app on Base44, it works, and you shipped it. Then a quieter worry surfaces: somewhere in all that AI-generated code is your Stripe key, your OpenAI key, maybe your email password, and you have no idea where they ended up. The AI builder put them wherever was fastest. If even one is sitting in code the browser downloads, anyone who opens developer tools can read it, copy it, and start spending your money. This is the single most common and most embarrassing exposure we find, and it is entirely fixable.
Base44 API key management comes down to one non-negotiable rule: a secret must never reach the browser. The AI builder routinely pastes Stripe, OpenAI, and email API keys straight into front-end code, where anyone can read them in seconds using developer tools. Every secret belongs in a server-side backend function, loaded from an environment variable the browser never sees. Scope each key to the minimum it needs, rotate it the moment it is exposed, and add monitoring so a leak does not run silently. Roughly one in three apps we audit has at least one key sitting in plain sight.
Why Base44 Puts Your API Keys in the Browser
This problem is not your fault. When you ask the AI builder to "connect Stripe" or "use OpenAI to summarize this," its goal is a working demo as fast as possible. The fastest path is to call the third-party service directly from front-end code, which means the key has to sit right there in the browser. The AI never reasons about who can read that code later, because confidentiality never shows up in a happy-path demo. It works, the feature ships, and the key is now public.
What makes this dangerous is that it is invisible while everything looks fine. Your app runs perfectly and payments go through. But "front-end code" is downloaded to every visitor's browser, and a downloaded file can be read by anyone who opens developer tools, a 15-second skill. There is no such thing as a hidden key in front-end code. Minifying or obfuscating it changes nothing; the running browser must have the real value, so it is always recoverable.
Based on the 100+ Base44 apps we have shipped or debugged, exposed secrets are the second most common critical finding after broken access control, which we cover in our Base44 authentication patterns guide. Both come from the AI trusting the front end with something only the server should hold. For the broader lockdown, see our Base44 security hardening checklist.
Where Secrets Should Actually Live: Server-Side Functions and Environment Variables
The correct architecture is simple and the only one that is actually safe. The browser should never hold a secret. Instead, it sends a normal request to your own backend function, and that function, running on a server the user cannot inspect, holds the API key and makes the call to Stripe or OpenAI on the browser's behalf. The key lives in a server-side environment variable, a configuration value injected at runtime and readable only by server code. The browser sees the result, never the key.
The mental model in one sentence: the browser asks your server to do the sensitive thing, and your server, holding the secret, does it. The Base44 implementation is to put every third-party call inside a backend function, read the key from process.env or the platform's secrets store, and have your front end call your function instead.
| Secret type | Wrong place (browser) | Right place (server) |
|---|---|---|
| Stripe secret key | Inlined in checkout component | Backend function, env var |
| OpenAI / LLM key | Front-end fetch call | Backend function, env var |
| Email/SMTP password | Config object in client code | Backend function, env var |
| Database connection string | Anywhere the browser loads | Server runtime only |
| Webhook signing secret | Hardcoded constant | Env var, verified server-side |
| Admin/service tokens | Front-end "admin mode" flag | Server, never exposed |
A second rule sits underneath the first: scope every key to the minimum it needs. Most providers let you create restricted keys. A Stripe key that can only create payment intents cannot issue refunds or read your customer list, so a leak is far less catastrophic. An OpenAI key with a spending cap cannot generate a $40,000 bill overnight. Scoping turns a disaster into an inconvenience. The OWASP Top 10 in Base44 covers where secret exposure sits among the standard risk categories.
How to Check If Your Base44 API Keys Are Already in Code
You can run this check yourself in five minutes, and every founder should before launch. Open your live app, press F12 for developer tools, and go to the Sources tab. Search (Cmd/Ctrl + Shift + F) for the telltale prefixes: sk_live and sk_test for Stripe, sk- for OpenAI, AKIA for AWS, Bearer for generic tokens, and the word password. Then on the Network tab, reload, click through your app, and watch whether any outgoing request carries a key the browser itself supplied.
If you find a key, it has leaked. Treat it as compromised even if you think nobody noticed, because automated scanners crawl public sites and GitHub repos constantly for exactly these strings. Also check the provider dashboards: Stripe's API logs, OpenAI's usage graph, and your email provider's send history for activity you cannot account for. Unexplained usage is the clearest sign a key is being abused right now.
| Provider | Key prefix to search | Where to verify leak |
|---|---|---|
| Stripe | sk_live, sk_test, rk_ | Dashboard → Developers → Logs |
| OpenAI / Anthropic | sk-, sk-ant- | Usage dashboard |
| AWS | AKIA, aws_secret | CloudTrail, IAM access keys |
| SendGrid / Postmark | SG., server token | Activity / message stream |
| Generic API | Bearer , api_key= | Provider request logs |
This check catches the loud cases. What it misses are subtler leaks: a key passed through an intermediate request, a secret in a source map, or a token that loads only on one rarely-visited page. Finding those takes someone who has seen how Base44 bundles its code, the gap between a self-check and a full Base44 AI builder audit. A $497 audit inspects every page, backend function, and build artifact for exposed secrets and hands you a list.
What to Do If a Key Already Leaked: Rotation Done Right
If you have confirmed a leak, do not panic and do not delete the key first. Order matters, because doing it backwards takes your app down. Base44 secrets rotation follows a strict sequence: generate the new key, install it, verify, then revoke the old one. Reverse the last two steps and your app calls a dead key, breaking for every user until you scramble.
Here is the exact runbook we follow, and you can too:
- Generate a new key in the provider's dashboard. Do not touch the old one yet.
- Add the new key to your Base44 environment variables as a secret, replacing the old value.
- Deploy and verify the feature still works end to end with the new key.
- Revoke the old key only after step 3 passes.
- Audit the provider's usage logs for the exposure window, checking for fraudulent charges or unexpected calls.
- Move the key server-side if it was in the browser. Rotation alone does not fix the architecture; a new key inlined in the front end leaks just as fast.
| Leaked key | How fast to rotate | Why the urgency |
|---|---|---|
| Stripe live secret | Immediately, before anything | Direct financial loss, refunds, fraud |
| Payment-adjacent token | Immediately | Can move money or read PII |
| LLM/OpenAI key | Within hours | Runaway billing, quota theft |
| Email/SMTP | Within hours | Spam from your domain, reputation damage |
| Read-only/restricted key | Same day | Lower blast radius but still rotate |
The most expensive mistake we see is treating rotation as the whole fix. A founder rotates a leaked Stripe key, feels relieved, and leaves the new key in the same front-end file; within a day it is exposed again. Rotation closes the current breach, but moving the key server-side closes the door. If the AI inlined the key, assume it will again on the next edit. If this is past your comfort level, our fix-sprint service moves every key server-side, rotates the compromised ones, and adds leak detection, a $1,500 sprint delivered in 48 to 72 hours with a money-back guarantee.
Monitoring and Leak Detection So It Does Not Happen Silently
Prevention is half the job; the other half is knowing the instant something goes wrong. A leaked key nobody notices for three weeks is far worse than one caught in an hour. Three layers of monitoring give early warning with little effort.
First, enable secret scanning on your code repository. If your Base44 project syncs to GitHub, its free secret scanning and push protection will block or alert on a committed key. Second, set spending alerts and usage caps on every provider. A hard monthly cap on your OpenAI key turns a stolen key from a financial event into a notification, and Stripe's alerts do the same for payments. Third, log every call your backend functions make to a third party, so you can tell what your app did from what an attacker did with a stolen key. All three take minutes and cost nothing.
The threat unique to Base44 deserves a mention. Because the AI builder re-inlines a key whenever it is the fastest path to a working feature, your front end can become unsafe again after an unrelated edit. Make a five-minute developer-tools recheck part of every release. It is the same silent-regression pattern we document across access control, and it is why a one-time cleanup is never the end of the story.
Do and Don't: The Base44 Secrets Cheat Sheet
If you remember nothing else, remember this table. It distills every secrets engagement we have run, and following it puts you ahead of most Base44 apps in production today.
| Do | Don't |
|---|---|
| Store every secret in a server-side environment variable | Hardcode keys in front-end components |
| Call third parties from a backend function | Call Stripe/OpenAI directly from the browser |
| Use restricted, minimally-scoped keys | Use a full-access key "to be safe" |
| Set spending caps and usage alerts | Assume nobody will find or abuse a key |
| Rotate immediately on any suspected leak | Wait to see if anyone noticed |
| Generate new key before revoking old | Revoke first and take the app down |
| Re-check developer tools after every AI edit | Trust that a key stays server-side forever |
| Enable repo secret scanning | Commit .env files or keys to GitHub |
| Keep production and test keys separate | Reuse one key everywhere |
| Get an audit before handling payments | Find out the hard way via a drained account |
A few deserve emphasis. Keeping production and test keys separate means a test-environment leak cannot touch real money. Never committing a .env file prevents an entire class of leaks. And the developer-tools recheck after every AI edit catches the regressions the platform keeps introducing. The lead engineer at Base44Devs treats that recheck as non-negotiable on every engagement.
Get Your Keys Verified Before They Cost You
If your app touches payments, an LLM, or any paid third-party service, the smartest few hundred dollars you will spend is confirming where your secrets live before an attacker does it for you. A $497 audit inspects every page, backend function, and build artifact, finds any exposed key, and hands you a written report with each leak's location and a remediation plan in one business day. If we find a critical exposure, that fee credits against the fix. If you would rather we handle the cleanup, our fix-sprint moves keys server-side, rotates the compromised ones, scopes them down, and wires up leak detection, a $1,500 sprint with a money-back guarantee if it is not resolved in 48 to 72 hours.
The decision is straightforward. You can spend five minutes today searching developer tools for sk_live. Or you can find out when your Stripe dashboard shows refunds you did not issue or your OpenAI bill arrives with an extra zero. The first path is cheap and quiet; the second is expensive and public. If your app is anywhere near real money, book a free 15-minute scoping call and we will tell you where your keys stand before they become someone else's.
Related reading
- Base44 Authentication Patterns — the access-control side of trusting the front end too much, the cousin of leaked secrets.
- Base44 Security Hardening Checklist — the full lockdown procedure that secret management sits inside of.
- OWASP Top 10 in Base44 — where exposed secrets rank among the industry-standard risk categories.