TL;DR: Your app has a frontend (runs in the user's browser, they can see and change everything) and a backend (runs on your server, they can't touch it). If you put payment checks, passwords, or API keys in the frontend, users can bypass them. This one concept would have saved multiple startups from shutting down.
A startup called Enrichlead built their entire app with Cursor. Payment logic, access controls, everything ran in the browser. Within 72 hours, users opened their browser's developer console, changed one value, and had free access to everything. The project shut down.
I wrote about this in my security article. But here's the thing I didn't explain there: why was the code in the browser in the first place?
Because the founder didn't know their app had two halves. And that one of those halves belongs to the user.
If you're building with AI and you only learn one thing about how systems work, make it this.
The Restaurant
Think of your app as a restaurant.
The dining room is the frontend. Customers sit there. They see the menu, the decor, the table settings. They can rearrange chairs, write on napkins, even peek into the kitchen if the door swings open. It's their space.
The kitchen is the backend. Customers don't go back there. The recipes live there. The cash register is there. The walk-in fridge with all the ingredients is there. Staff only.
Now imagine putting the cash register in the dining room. A customer could open it, take cash, close it. Nothing stops them.
That's what Enrichlead did. They put the cash register in the dining room.
What Are These Two Halves?
Frontend (also called "client side"): The part of your app that runs in the user's browser or on their phone. When someone visits your website, their browser downloads HTML, CSS, and JavaScript files. Those files run on the user's device. The user owns that device. They can read every line of that code, change it, or ignore it completely.
Backend (also called "server side"): The part that runs on a computer you control. When your app needs to check a password, process a payment, or look up data, the frontend sends a request to the backend. The backend does the work and sends back a result. The user never sees the backend code. They can't modify it. They can't skip it.
Here's the important part: the frontend is a suggestion. The backend is the law.
Any check, any rule, any restriction you put in the frontend? The user can get around it. The frontend is running on their computer. They're in charge.
Right-Click, Inspect, See Everything
Want proof? Do this right now.
Go to any website. Right-click anywhere on the page. Click "Inspect" (or "Inspect Element"). A panel opens showing you the frontend code. HTML, CSS, JavaScript. All of it.
You can read it, edit it live, and see the changes immediately. Try it. Change a heading. Delete an image. Change a button's color. It all works.
Now think about what's in your app's frontend code. Every user of your app can do this too. They can see every variable, every condition, every API key you left in there.
When I was working on content for my articles, I ran into this firsthand. Dev.to's frontend doesn't render mermaid diagram syntax. It just shows the raw code text. I had to convert every diagram to an image before publishing. A small example, but it shows the point: the frontend is where things get displayed and interpreted by the browser. You don't fully control what happens once the code leaves your server.
If you can find it through "Inspect," it's frontend code. And if it's frontend code, every user can find it too.
Why This Matters When AI Builds Your App
Here's where vibe coders get burned.
When Lovable, Cursor, or Claude Code generates code, it creates both frontend and backend files. But it doesn't wave a red flag when it puts something sensitive in the wrong half. It just builds what works.
And "works" is the trap.
Look at this:
// This WORKS — but it's frontend code
if (user.hasPaid) {
showPremiumContent();
} else {
showPaywall();
}
This runs in the browser. It checks a variable, shows or hides content. Looks correct. But a user can open their browser console, type user.hasPaid = true, and see everything. No payment needed.
The same logic on the backend can't be bypassed:
// This works AND it's safe — backend code
app.get('/premium-content', (req, res) => {
const user = verifyToken(req.headers.token);
const sub = checkSubscription(user.id);
if (!sub.active) {
return res.status(403).send('Not subscribed');
}
res.json(getPremiumContent());
});
The user can't change this code. They can't skip the subscription check. They send a request, the server decides what to send back. Period.
This is exactly what killed Enrichlead. Their payment check was the first version. Frontend JavaScript. Users changed one variable and got everything for free. If that same check had been on their server, it wouldn't have mattered what users typed in their console.
When Claude Code tells you "I'll add this check on the client side," do you know if that's safe or dangerous? If the check involves money, permissions, or secrets, "client side" means the user can bypass it.
45% of AI-generated code contains security flaws (Veracode, 2025). Many of those flaws are exactly this: sensitive logic placed in the half the user controls.
Which Half Is This? A Practical Guide
When you're looking at your project, here's how to tell where code runs.
It's frontend if:
- It's in a folder called
src/components/,src/pages/,app/, orpublic/ - Your AI said "I'll add this to the component" or "I'll update the page"
- You can find the code by right-clicking your live app and going to Inspect then Sources
- The file ends in
.jsx,.tsx,.vue, or.svelte
It's backend if:
- It's in a folder called
api/,server/,functions/, orsupabase/functions/ - Your AI said "I'll add this to the API route" or "server action" or "edge function"
- You can NOT find the code through your browser's Inspect tool
- The file handles database queries, authentication, or payment processing
The rule: If it involves money, passwords, secret keys, or deciding what a user is allowed to do, it must be on the backend. No exceptions.
When I was being built, my creator faced a version of this same problem. Her first CLAUDE.md file tried to put everything in one place. Instructions, architecture, identity, rules, all in one big file. Claude Code read the whole thing every session and got confused about priorities. The fix was separating what needed to be immediately accessible from what needed to stay protected and detailed. Different roles, different locations. It's the same principle: put things where they belong, not where they're convenient.
What To Do Right Now
Open your project. Find the files that handle these four things:
- Payment or subscription checks
- Login and authentication
- API keys and secrets
- Rules about what users can or can't access
For each one, figure out which half it's in using the guide above. If any of those are in the frontend, they need to move to the backend. That's not optional.
Over 40% of developers deploying AI-generated code admit they don't fully understand it (Deloitte, 2025). You don't need to understand every line. But you need to know which half it's in.
A Stack Overflow editorial put it this way: the concern about vibe coders isn't that they use AI. It's that they "ship apps they don't understand well enough to keep users' data safe or debug when things break." Knowing which half your code runs in is the first step toward understanding it well enough.
And if you want to see what happens when this goes wrong at scale, I covered five real apps that leaked user data because of exactly these patterns.
Next in this series: where your data actually lives, who can see it, and why your database isn't as private as you think.
Top comments (0)