Guide · Launch

The security check before you launch.

Short answer: Before launch, check seven things: no secret keys in the code the browser downloads, database rules that keep strangers out, one customer unable to open another's data, private files not reachable from the web, limits on password guessing, a secure connection with security headers, and your email domain protected against forgery. Most of these take minutes to check and are the ones attackers try first.

Updated 25 October 2026

What to do, step by step

This is the short list for the week before launch, or before you start taking money. The longer list for growing up afterwards is the production readiness checklist.

  1. No secrets in the browser

    Search the scripts your site sends for secret keys (Stripe sk_live_, Supabase service_role or sb_secret_, OpenAI sk-, database addresses with a password in them). In Next.js anything named NEXT_PUBLIC_… and in Vite anything named VITE_… is sent to every visitor. Details.

  2. Database rules switched on

    Supabase: Row Level Security on every table, with policies. Firebase: no rule that says allow read, write: if true, and test-mode rules replaced. How to check Supabase.

  3. Customers can only see their own data

    With two test accounts, try to open account A's records while signed in as B, by changing ids in the address or in the app's requests. Then try the same pages signed out.

  4. Private files are not public

    /.env, /.git/config, backups such as /backup.zip or /db.sql, and admin tools should all answer "not found" or ask for a password. Details.

  5. Sign-in can't be guessed at will

    Rate limits on sign-in and password reset, reset links that expire, and email confirmation on sign-up. Turn on two-factor sign-in for your own admin accounts (hosting, domain, database, payments, GitHub).

  6. Secure connection and headers

    Every address redirects to https://, and the site sends the six security headers. How to set them.

  7. Your email domain can't be faked

    SPF, DKIM and DMARC records on your domain stop someone sending invoices "from" you, and keep your own mail out of spam. How to set them up.

  8. Remove what was only for you

    Test accounts with easy passwords, debug pages, console.log output with customer data, and sample data in the live database.

What vibeship checks for you

You can do all of the above by hand. If you'd rather start with a list of what's wrong, the vibeship quick check runs from outside, the way a stranger sees your site. The quick check is free and needs no account. It shows your grade and how many problems sit in each area; what each problem is and how to fix it is in the full report.

Checked automatically

  • Steps 1, 4, 6 and 7 from outside, automatically, in about a minute
  • Step 2 for Supabase and Firebase: whether a stranger can count the rows in sensitive tables
  • Leftover developer code (step 8) in the scripts your site ships
  • Outdated PHP, a passive look for known misconfigurations, legal pages and speed

Deeper, and what we don't check

  • Step 3 and step 5 need a signed-in test: the deep test with a subscription does both
  • The extensive scan (free with an account) adds a real break-in attempt from outside
  • Not checked: your test accounts, your admin two-factor settings, your backups

Questions people ask

When should I run a security check: before launch or after?

Both. Once before launch or before taking money, and again after every larger change. Problems introduced by an AI edit look exactly like everything else in the app.

Is this list enough for a security questionnaire from a customer?

It covers the questions small customers ask first. Larger customers will ask about backups, access to production, incident handling and sometimes a third-party penetration test, which this list does not cover.

What is the most common problem on newly launched apps?

On apps built with AI tools, the classic two are database rules left open and secret keys shipped to the browser. Both are quick to fix and both are exactly what automated attack tools look for first.

Best effort, not a guarantee: Our scans are best effort: they can miss a weakness or flag one that isn't there. This is advice, not a guarantee, and it doesn't replace a security firm. Your site's safety stays your responsibility. Read the terms.

Sources

Sources checked on 25 October 2026.

Related guides