The vibe coding security checklist for people who've never run a server

You built an app with an AI tool, it works, and now people are starting to use it. Somewhere in the back of your head there’s a worry: is this thing safe? You don’t know what “safe” even means here, and every guide you find assumes you already run servers for a living. This one doesn’t.

Here’s a checklist you can actually work through, with every term explained the first time it shows up.

Why this happens

AI coding tools are good at making an app that runs. They’re bad at telling you what you skipped. The tool writes working code, shows you a live preview, and stops there. Security isn’t a feature you can see, so it never comes up.

The result is that thousands of AI-built apps go live with the front door wide open. Not because the builder was careless, but because nobody told them there was a door. The gaps are almost always the same seven things. Once you know their names, you can check each one in an afternoon.

How to fix it

Work down this list in order. Each item has a “what it means” and a “how to check.”

1. SSL (the padlock in the browser)

SSL is the thing that turns http:// into https://. It encrypts the connection between your user’s browser and your app, so nobody sitting on the same coffee-shop WiFi can read passwords or data in transit. The padlock icon in the address bar means it’s on.

How to check: open your live app and look at the address bar. If it says https:// and shows a padlock, you’re fine. If it says “Not secure,” that’s your first job. Most hosting platforms turn this on for free automatically, so usually the fix is just flipping a setting.

2. Environment variables (env vars)

An environment variable is a secret value your app needs, like a password to your database or an API key for a service you pay for. The word “environment” just means “the place your app runs.” These values are supposed to live in a settings panel, not in your code.

How to check: search your project for anything that looks like a long random string. In most AI tools you can open the code view and use find (Ctrl+F or Cmd+F):

# if you have the code on your computer, run this in the project folder
grep -rEi "(api[_-]?key|secret|password|token)\s*[:=]\s*['\"][A-Za-z0-9]{16,}" .

If that turns up a real key sitting in a code file, move it to your platform’s secrets or environment settings, then rotate the key (generate a new one and delete the old). A key in code is a key anyone who sees the code can use.

3. Row-level security (RLS)

If your app uses a database, RLS decides which rows of data each user is allowed to see. Without it, a logged-in user can often ask the database for everyone’s records, not just their own. This is the single most common serious bug in AI-built apps that use Supabase.

How to check: if your database is Supabase, open the dashboard, go to Authentication then Policies, and confirm every table with user data has RLS enabled and at least one policy. A table showing “RLS disabled” is readable by anyone with your public key, which is printed in your app’s code.

We wrote a full walkthrough on this in Supabase row-level security exposed.

4. Who can sign up

Many AI-built apps ship with open sign-up, meaning anyone on the internet can create an account. Sometimes that’s what you want. Often it isn’t, and it becomes a spam and abuse problem the moment you get attention.

How to check: try to sign up for your own app using a fake email in a private browser window. If it lets you straight in with no limits, decide whether that’s intended. If it isn’t, add email confirmation or an invite step.

5. Debug mode

Debug mode is a developer setting that makes your app print detailed error messages. Those messages are great while you’re building and dangerous once you’re live, because they can leak database details, file paths, and secrets straight to a visitor who triggers an error.

How to check: look for a setting called DEBUG, NODE_ENV, or “development mode.” In production it should be DEBUG=false or NODE_ENV=production. If you’re not sure, deliberately break something (visit a page that doesn’t exist) and see if the error page dumps a wall of technical detail. It shouldn’t.

6. Backups

A backup is a saved copy of your database you can restore if something goes wrong. Deleted data, a bad migration, a corrupted table: without a backup, any of those is permanent.

How to check: find out if your platform takes backups, how often, and how far back they go. Then, and this is the part everyone skips, confirm you know how to restore one. A backup you’ve never restored is a guess. Our backup and restore tutorial shows the whole loop.

7. Rate limiting

Rate limiting caps how many requests one visitor can make in a short window. Without it, a single script can hammer your login page or your API thousands of times a second, running up your bill or knocking the app over.

How to check: this one’s harder to test by hand. If your app has a login form, a signup form, or any public API endpoint, it should have a limit. If you’re not sure it does, assume it doesn’t. Our 20-minute hardening pass covers how to add one.

Or, we do it for you

We run a free audit that checks all seven of these on your live app and hands you a plain-English report, no jargon, no upsell required to read it. Book your free audit and we’ll tell you exactly which doors are open.

FAQ

Do I need to understand all of this to be safe?

No. You need to know the seven things exist and get each one to a safe state. You can check most of them by clicking around your own app and your platform’s settings. The hard part is knowing they exist, which is what this list is for.

My app is tiny and nobody uses it yet. Does this matter?

The two that matter even at zero users are exposed keys and RLS, because both leak the moment your app is public, users or no users. A bot scanning the internet doesn’t care how popular you are. Do those two now, do the rest before you promote the app.

What’s the difference between an API key and a password?

A password is for a human logging in. An API key is a password for your app when it talks to another service, like a payment provider or an email sender. Both are secrets, both belong in environment variables, and both should be rotated if they ever end up in your code or a screenshot.

Is Supabase or Lovable insecure?

No. The tools are fine. The gap is that a working preview looks identical whether these settings are safe or not, so beginners have no signal that anything’s missing. The checklist is how you get that signal.