Pre-launch security checklist — 7 checks you can do in an evening

Here's the uncomfortable truth: the moment your app appears online, bots start probing it — automatically, around the clock, with no personal grudge against you. That's not a reason to fear launching, it's a reason to close a few obvious holes in advance. The good news: for a first project a short list is enough. Run these seven items in an evening and you're no longer "easy prey."

1. Keys are not in the code

What: move every API key, password and database address into environment variables, in a .env file. In the code — only process.env.NAME.

Why: a key written into code that lands in a repo gets stolen by bots in minutes and spends your money.

The catch: moving the key isn't enough — check that .env is listed in .gitignore, or it ships to the repo with the code anyway.

2. Secrets didn't leak to the browser

What: make sure server keys don't reach the frontend. Anything sent to the browser is visible to anyone via "Inspect."

Why: beginners often put a secret key where it renders into the page. In most frameworks, variables prefixed like NEXT_PUBLIC_ or VITE_ go to the browser on purpose — never put secrets there.

The catch: open the live page, hit "View source" and search for your keys. Found one? That's a leak; move the call to the server.

3. Database access is locked by rules

What: turn on row protection (on a Supabase database that's RLS) and set rules: a user sees only their own rows.

Why: without rules, the public key lets anyone read or wipe the whole table — other people's notes, other people's orders.

The catch: RLS on with no rules blocks everything, and it looks like "the database broke." That's normal: add a rule "a row is visible to its owner."

4. The site runs over HTTPS

What: check that the address starts with https://, not http://. The padlock in the address bar.

Why: over plain http, data travels as clear text — a password can be intercepted on public Wi-Fi.

The catch: nearly all modern hosts (Vercel, Netlify) give HTTPS for free and automatically. Just confirm it's on and there are no mixed http links inside the page.

5. Login isn't hand-rolled

What: don't store passwords yourself and don't write your own auth. Take a ready login service (Supabase Auth, Auth0, sign-in with Google).

Why: storing passwords safely is its own science (hashing, salt, brute-force defense). A homemade version is almost certainly leaky.

The catch: even with a ready service, don't forget password reset and email confirmation — providers offer them out of the box, but you switch them on by hand.

6. User input is validated

What: don't trust what the user sends. Validate on the server: type, length, format — even if the form already checks it.

Why: browser-only validation is bypassed in a second. Via the API a request can be sent directly, skipping your pretty form.

The catch: "front-end validation" is about convenience, not security. Real protection is always on the server; treat the client check as a hint, not a barrier.

7. There are limits on requests

What: add rate limiting on heavy and paid actions — login, form submissions, paid AI calls.

Why: without a limit, one script can make a million requests overnight — take the service down or burn your AI budget.

The catch: you don't have to build this yourself — many hosts and API gateways enable rate limiting via a setting. The point is not to leave paid endpoints with no limit at all.

Is this the complete list?

No — it's the floor for a first launch, not an audit for a bank. But these seven items close the mistakes people get burned on most. Do them and you're already safer than most side projects online. As your audience grows, you'll add the next levels.

Question: will I really get attacked right after launch?

Not "attacked" personally — but scanned automatically, yes, almost at once. Bots constantly sweep new addresses looking for exposed keys and unprotected databases. They don't care who you are; they look for easy doors. These seven items are exactly about not having any easy doors.

Question: won't the AI agent make it all secure for me?

Partly. Modern agents usually split keys into .env and take ready auth — that's good. But database access, limits and browser leaks are still worth checking yourself: an agent writes "so it works," not "so it's protected." This checklist is your way to check after it.