You vibe-coded an app. Is it safe to launch?

Databases get leaked all the time: a stolen backup, an exposed admin panel, a bad query. When that happens, what’s stored in the password column decides how bad the day is. People reuse passwords, so a leak of your app’s passwords is also a leak of their email, bank, and Instagram passwords.

How to check2 min

Open your users table and look at the password column.

How to fix

Hashing means turning the password into a scrambled string that can’t be turned back. At login you hash what the user typed and compare the two scrambles. You never need to know the real password.

Use a slow hashing method built for passwords: bcrypt or Argon2. Never write your own.

const bcrypt = require("bcrypt"); // On signupconst hash = await bcrypt.hash(password, 12);await db.users.insert({ email, password_hash: hash }); // On loginconst ok = await bcrypt.compare(typedPassword, user.password_hash);

A rate limit is a rule like “one person can try to log in 5 times per 15 minutes.” Without it:

• Password guessing. A script tries thousands of passwords on one account until it gets in.
• Taking you down. Flood any endpoint and your server or database chokes. That’s a Denial of Service (DoS) attack.
• Burning your money. Spam your signup (each one sends an email or SMS you pay for) or your AI endpoint. You find out when the bill arrives.

How to check2 min

Run this against your own login endpoint and look at the status codes:

# Sends 50 login attempts in a rowfor i in $(seq 1 50); do  curl -s -o /dev/null -w "%{http_code}\n" -X POST https://yourapp.com/api/login \    -H "Content-Type: application/json" -d '{"email":"test@test.com","password":"wrong"}'done

All 50 come back 401? No rate limit. You want 429 (“Too Many Requests”) after a handful.

How to fix

Put strict limits on the endpoints that matter most, and a looser limit on everything else:

const rateLimit = require("express-rate-limit"); const loginLimiter = rateLimit({  windowMs: 15 * 60 * 1000,  // 15 minutes  limit: 5,                  // 5 attempts per window}); app.post("/api/login", loginLimiter, loginHandler);

These limits stop one person with a script. A flood from thousands of machines has to be stopped before it reaches your server: put your domain behind Cloudflare (the free plan covers most of it).

A secret is anything that lets someone act as you: API keys (OpenAI, Stripe, AWS), database passwords, tokens. Bots scan public GitHub repos around the clock and find leaked keys within minutes. And if your code ships to the browser, anyone can press F12 and read it.

How to check5 min

1. Search your project for sk-, sk_live, AKIA, api_key, secret, password, token.
2. Open your live site, press F12, go to the Sources tab, and search the JavaScript files for the same words. Anything you find there, the whole world can find.
3. Check that .env is listed in your .gitignore.
4. Check your git history, not just today’s code. A key you deleted last week is still in old commits. Run gitleaks on the repo to scan everything at once.

How to fix

// Bad: key sits in the codeconst openai = new OpenAI({ apiKey: "sk-proj-abc123..." }); // Good: key comes from the environmentconst openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

• On your laptop: put secrets in a .env file that’s in .gitignore, so it never gets committed.
• In production: put them in your host’s environment variables (Vercel, Railway, Render all have a settings page for this), or a proper secrets store like AWS Secrets Manager once you have more than a few.
• Never in the frontend. Anything prefixed NEXT_PUBLIC_ or VITE_ is sent to every visitor’s browser. Paid API calls (OpenAI, Stripe) must go through your backend.

After launch, bug reports sound like “it’s not working.” That’s all you’ll get. Logs are what turn that into something you can fix. For every error, you want to know:

How to check2 min

Break something on purpose: add a route that throws an error, visit it on your live site, then ask yourself: can I find that error in under a minute, without SSH-ing into anything? If not, you don’t have logging yet.

How to fix

The fastest setup is an error tracker like Sentry (the free tier is plenty to start). It catches crashes on both the frontend and backend, shows you the user, page and time, and emails you when something new breaks.

// One command sets up frontend + backendnpx @sentry/wizard@latest -i nextjs // Attach the logged-in user so every error shows who hit itSentry.setUser({ id: user.id });

Besides errors, also log these events so you can spot trouble:

• Failed logins (lots of them = someone guessing passwords)
• Password changes and resets
• Payments and refunds
• Anything an admin does

One wrong DELETE without a WHERE. One AI agent that “cleans up” a table. One migration that drops a column. It happens to experienced engineers too. If there’s no recent backup, those 10,000 users are gone, and so is the business.

How to check2 min

Answer these three questions honestly:

1. Are backups turned on and automatic? Check your database provider’s dashboard. Don’t assume, and read what your plan actually includes. Free tiers often keep few or no backups.
2. How much would I lose? Daily backups mean up to 24 hours of data lost. If that’s too much, turn on point-in-time recovery (restore to any minute).
3. Have I ever restored one? If the answer is no, you don’t know if it works.

How to fix

• Managed database (Supabase, Neon, AWS RDS, PlanetScale, Firebase): turn on automatic backups in the dashboard, and point-in-time recovery if you can afford it.
• Your own server: schedule a nightly dump and copy it somewhere else, like S3 or Cloudflare R2. A backup on the same server dies with the server.

# Nightly dump, run by a cron job at 2ampg_dump "$DATABASE_URL" -Fc -f backup_$(date +%F).dump # Restore into a SEPARATE test database to prove it workspg_restore -d "$TEST_DATABASE_URL" --clean backup_2026-09-21.dump

Do a test restore today

1. Take your latest backup.
2. Restore it into a new, empty database (never on top of production).
3. Count the rows in your main tables and compare with production.
4. Point a local copy of your app at it and log in.
5. Write down how long it took. That’s how long you’d be down in a real emergency.

Here’s how it goes wrong. Your app loads an order with /api/orders/1042. It checks that you’re logged in, but not that order 1042 is yours. Change the number to 1041 and you’re looking at a stranger’s order: their name, address, phone number.

How to check5 min

1. Create two accounts: A and B.
2. Logged in as A, create something (a profile, an order, a note). Copy its URL or API call from the Network tab (F12).
3. Log in as B and open that same URL or repeat that API call.
4. If B can see or edit A’s data, you have a problem.

How to fix

Every query that reads or changes user data must also check who owns it:

// Bad: returns any order to anyone logged indb.orders.find({ id: req.params.id }); // Good: only returns it if it belongs to this userdb.orders.find({ id: req.params.id, user_id: req.user.id });

• Using Supabase? Turn on Row Level Security (RLS) for every table and add policies so users can only read and write their own rows. With RLS off, your public anon key lets anyone read the entire table.
• Using Firebase? Make sure your Firestore rules aren’t still in test mode (allow read, write: if true).