You built something real. Your app has users, maybe payments, probably a database with real data. You used an AI coding tool to get there — Lovable, Bolt.new, Cursor, Replit, or one of the others — and it worked.
Now someone asks you: "Is it secure?"
This guide answers that question honestly, without assuming you know what CORS or RLS means. If you shipped a vibe-coded app and want to understand what's at risk and what to do about it, this is for you.
Why AI-built apps have predictable security gaps
When you build an app manually, you make hundreds of small decisions: who can access this route, where does this secret go, should this data be visible to unauthenticated users. Security is woven into those decisions.
When an AI builds your app, it makes those decisions automatically — and it defaults to "make it work." That means API routes that accept any request, database tables without access controls, secrets stored in the code, and missing security headers.
None of this is a bug in the AI tool. It's the predictable result of optimizing for a working demo rather than a production app. The good news: the gaps are consistent and fixable.
The five things most likely to be exposed in your app
1. Your database has no access controls
Most AI-built apps use Supabase for their database. Supabase is excellent, but it ships with Row Level Security (RLS) turned off by default.
RLS is the feature that controls who can read and write which rows. Without it, any user of your app — or anyone who finds your API key — can read every row in every table.
What that means in plain English: If your app stores user profiles, orders, messages, or any other data, and RLS is off, any user can read every other user's data by making a direct API call.
How to check: Log into your Supabase dashboard, go to the Table Editor, and look for a shield icon next to each table. A red shield means RLS is disabled.
2. API routes that don't check who's asking
Your app has API endpoints — URLs that your frontend calls to get data or perform actions. AI tools generate these routes focused on functionality, which means they often skip the step that checks if the person making the request is allowed to.
What that means: An endpoint like /api/users/profile might return user data without checking if the request comes from a logged-in user — or from the right user. Anyone who finds the URL can call it.
How to check: Look at your API route files. Every route that returns user data or performs an action should have a line near the top that verifies the user's session or token.
3. API keys visible in your frontend
Every web app makes calls to external services — Stripe, OpenAI, SendGrid, Google Maps. To do that, it needs an API key. AI tools sometimes generate code that puts these keys directly in the JavaScript that runs in the browser.
What that means: Anyone who visits your site can open DevTools → Sources and search for your API keys. They can then use those keys to charge things to your Stripe account, run up OpenAI bills, or send email from your SendGrid account.
How to check: Open your deployed app in a browser. Press Command+Option+J (Chrome DevTools). Click Sources → search for "sk-" (OpenAI), "sk_live" (Stripe), or "SG." (SendGrid). If you find them, they're exposed.
4. Security headers are missing
Security headers are instructions your server sends with every page that tell browsers how to behave. Without them:
- Your app can be embedded in an iframe on another site, which enables "clickjacking" attacks where users think they're clicking on your app but are actually clicking on something else
- Browsers will load insecure resources even on HTTPS pages
- Attackers who find a vulnerability can inject scripts that steal data from your users
What that means: Missing headers are an amplifier. They don't cause attacks on their own, but they make the impact of other vulnerabilities much worse.
How to check: VibeScan checks all of these automatically and tells you which ones are missing.
5. Internal routes are exposed in search engines
AI-built apps sometimes include admin routes, internal dashboards, or API endpoints in their robots.txt file — a file that tells search engines what to index. Paradoxically, listing something in robots.txt to tell Google not to index it also tells attackers it exists.
What that means: If your /admin or /api/internal routes are in robots.txt, anyone who reads that file knows to look there.
What to do right now
If your app has real users and real data, take these four actions this week — in order of urgency:
1. Enable RLS on every Supabase table. Log in to Supabase, go to Authentication → Policies, and enable Row Level Security on every table. This is the single highest-impact security change you can make.
2. Check for exposed API keys. Open DevTools on your live site and search for API keys in the page source. Revoke and regenerate any key that's exposed, and move it to an environment variable.
3. Run a VibeScan scan. Point VibeScan at your deployed app and you'll get a complete picture of what's visible from outside in under 60 seconds. This covers the headers, CORS policy, secrets, and other issues that are hard to check manually.
4. Add security headers. Create a vercel.json file with the four standard security headers. This takes five minutes and fixes several categories of vulnerability at once.
The honest answer to "is my app secure?"
No app is completely secure. The goal is to fix the most impactful gaps first — the ones that could let someone read your users' data, take over accounts, or rack up charges on your API keys.
For most vibe-coded apps, those gaps are predictable and fixable. The risk isn't that someone built a sophisticated zero-day exploit targeting your app. The risk is that your database has no access controls and someone curious enough to open DevTools can read everything.
Fix the basics, run a scan, and you'll be ahead of most apps at your stage.