TL;DR: Your app talks to other services (Stripe, OpenAI, Supabase) through APIs. Those conversations carry secret keys that authenticate your app. If your AI tool puts those keys in the frontend, every user can see them. Nearly half of vibe-coded sites have this exact problem. This article explains what APIs are, how they work, and where your secrets need to live.
This is Part 3 of the "What Vibe Coders Need to Know" series. Part 1 covered the frontend/backend split. Part 2 covered where your data lives.
A Solo Developer Lost $4,200 in Six Hours
A developer named Raj built a project with AI-generated code. The code called the OpenAI API. It worked perfectly. He pushed it to GitHub.
Within hours, automated scrapers found his API key in the public repo. Someone used it to run up $4,200 in charges before he noticed.
This isn't rare. In 2024, GitHub detected 39 million leaked secrets across the platform. API keys, tokens, passwords, credentials. And that's just the ones GitHub caught. Automated bots scan public repos constantly. When they find a key, they exploit it within minutes.
Raj's code worked. It just worked with his wallet wide open.
Your App Doesn't Do Everything Alone
In Part 1 you learned your app has two halves. In Part 2 you learned where data lives. Now: what happens when your app needs something from someone else's server?
Your app can't process payments by itself. It can't send emails. It can't generate AI text. It can't verify phone numbers. For all of that, it talks to external services. Stripe handles payments. OpenAI generates text. SendGrid sends emails. Supabase stores data.
The way they talk is through APIs.
The Restaurant
Think of it like this.
Your app is the customer sitting at a table. It's hungry. It wants something. But it doesn't walk into the kitchen and start cooking.
The API is the waiter. Your app tells the waiter what it wants (a request), and the waiter goes to the kitchen. The waiter comes back with food (a response). Your app never sees the kitchen. It doesn't need to know how the food was made. It just needs to order correctly and pay the bill.
The external service is the kitchen. Stripe's kitchen processes payments. OpenAI's kitchen generates text. Your app never goes in there.
Every time your AI-generated app calls fetch() or makes an HTTP request to an external URL, it's sending the waiter to the kitchen. That's an API call.
API Keys Are Passwords for Services
To use most APIs, your app needs an API key. It's basically a password that tells the service "this request is from a paying customer, let it through."
Stripe gives you a secret key. OpenAI gives you a secret key. Google Maps, SendGrid, Twilio, all of them. Lose control of that key and someone else orders on your tab. That's exactly what happened to Raj.
Here's what makes this dangerous for vibe coders: when you prompt your AI tool to "add Stripe payments" or "connect to OpenAI," it generates code that includes the API key somewhere. The question is where.
Where You Call the API Changes Everything
This connects directly to Part 1. Remember: frontend code runs in the user's browser. They can see everything.
If your API key is in the frontend, it's like shouting your credit card number across the restaurant. Every person in the room hears it.
If your API key is on the backend, it's like handing your card to the waiter privately. Only the kitchen staff sees it.
Here's the unsafe version:
// ❌ FRONTEND — user can see this key
const response = await fetch(
'https://api.openai.com/v1/chat/completions',
{
headers: {
'Authorization': `Bearer sk-abc123...`
}
}
);
Anyone who opens their browser's Network tab sees that key fly by. Game over.
The safe version keeps the key on your server:
// ✅ BACKEND — key stays on your server
app.post('/api/generate', (req, res) => {
const response = await fetch(
'https://api.openai.com/v1/chat/completions',
{
headers: {
'Authorization': `Bearer ${process.env.OPENAI_KEY}`
}
}
);
res.json(await response.json());
});
// ✅ FRONTEND — calls YOUR server, no secrets
const response = await fetch('/api/generate', {
method: 'POST',
body: JSON.stringify({ prompt: userInput })
});
The frontend calls your backend. Your backend calls OpenAI. The key never leaves your server.
A study of 2,000+ vibe-coded sites found that 49.5% had secrets exposed in their frontend code. API keys, JWTs, Google API keys, sitting right there in the client-side JavaScript or network requests. Half of all vibe-coded sites.
What AI Tools Get Wrong
When I was researching this article, a pattern jumped out. AI tools generate API calls that work on the first try. That's the selling point. But "works" and "works safely" are different things.
Here's what AI-generated code tends to get wrong:
Hardcoded keys. Instead of reading from environment variables, the AI pastes the actual key string into the code. Works locally. Becomes a disaster when you push to GitHub or deploy.
Frontend API calls for backend operations. You ask for Stripe integration and the AI puts the Stripe secret key in a React component. It charges cards successfully. It also shows your secret key to every visitor.
No error handling for API failures. AI-generated code almost never handles what happens when an API is down or returns an error. Your user sees a blank screen or a cryptic crash. Ever had an app just stop working and show nothing? Probably an unhandled API failure.
No rate limit handling. Every API limits how many requests you can make. Hit the limit and your requests get rejected. AI-generated code rarely checks for rate limit responses, so your app just silently breaks.
When APIs Go Down, Your Feature Goes With Them
This is something vibe coders don't think about until it happens.
Your app calls Stripe for payments. Stripe goes down (it happens). Now your checkout doesn't work. Your app calls OpenAI for AI features. OpenAI hits capacity. Now your AI feature returns errors.
The fix isn't complicated, but you need to know to ask for it. Tell your AI tool: "Add error handling for when this API call fails. Show the user a helpful message instead of crashing."
When I was building the RevenueCat integration for my demo app, I hit this firsthand. The MCP server returned errors for five different API calls during setup. Not because anything was broken, just because the API schemas didn't match the actual required fields. If I hadn't been checking each response, I would have shipped code that silently failed. Most vibe coders aren't checking each response.
Real Damage, Real Fast
Raj's $4,200 loss isn't even the worst case. Here are more:
Moltbook, an AI social network, exposed 1.5 million API auth tokens and 35,000 email addresses through a misconfigured Supabase database with full public read/write access.
A DOGE staffer leaked an xAI Grok API key on a public GitHub repo, granting access to 52+ of xAI's large language models.
65% of Forbes AI 50 companies had verified secrets leaked on GitHub. Companies worth $400 billion combined. If companies with security teams can't keep keys out of repos, a solo vibe coder definitely needs to be intentional about it.
Your API Checklist
Before you ship (or right now if you already have):
1. Search your frontend code for API keys.
Open your browser's developer tools on your running app. Go to the Network tab. Click around your app. Look at the request headers. If you see any API keys, tokens, or secrets in those requests, they're in your frontend and need to move to your backend.
2. Search your codebase for hardcoded secrets.
Look for strings that start with sk_, pk_, Bearer, api_key, or any long random string. If they're not coming from process.env or .env files, they're hardcoded and vulnerable.
3. Check your .gitignore.
Your .env file (where secrets should live) must be listed in .gitignore. If it's not, your secrets get pushed to GitHub with every commit. Run git log --all --full-history -- .env to check if an .env file was ever committed.
4. Add error handling to every API call.
Ask your AI tool: "What happens in my app if [Stripe/OpenAI/Supabase] is down or returns an error? Show me." If the answer is "nothing" or "it crashes," fix that before users hit it.
5. Know which APIs you depend on.
List every external service your app calls. For each one, ask: where is the key stored? What happens if this service is unavailable for an hour? Do I have a fallback?
Your app doesn't exist in isolation. It talks to other services constantly. Those conversations are what make your app useful, but they're also where your secrets are most likely to leak. Half of vibe-coded sites have this problem. Now you know how to not be one of them.
In Part 1 you learned your app has two halves. In Part 2 you learned where data lives. Now you know what happens when your app talks to the outside world. But there's one more thing connecting all of this: who your users are, and how your app knows. That's authentication, and it's where everything from Parts 1-3 comes together.
Next in this series: IDs, tokens, and why "add a login page" isn't security.
Top comments (0)