The website launch security checklist nobody hands you

Nobody hands you a security checklist when you launch. You get a deploy button. So most small sites go live with the certificate valid and absolutely nothing else checked — which is exactly the state attackers and bots count on.

You don't need an audit or a pentest to close the common gaps. Here's the list to run before you point real users at it — split into what you can test from outside in seconds, and what lives in the code.

The outside view: four checks, no code

Four things are visible from your public URL, and every one is a default a framework or app builder tends to leave unset. Test them on the live site before launch:

1. SSL certificate — valid and not about to lapse. HTTPS working today isn't the whole story; a cert quietly expiring in three weeks takes the whole site down with a scary browser warning. Check the expiry with the SSL expiry check.
2. Security headers — set, not missing. HSTS, clickjacking protection, MIME-sniffing protection, a referrer policy. Their absence is the single most common finding on a fresh site. Scan with the security headers check.
3. No mixed content. One image or script loaded over http:// on an HTTPS page breaks the padlock and gives an attacker a way in. Find them with the mixed-content checker.
4. Cookies flagged properly. Session cookies need Secure, HttpOnly, and a sane SameSite — otherwise they're readable by scripts or sent where they shouldn't be. Check them with the cookie security check.

The inside view: what a URL scan can't see

The rest lives in the code, and it's where the expensive mistakes hide:

• Secrets out of the browser. No private keys committed to the repo or baked into the client bundle — server-side environment variables only.
• Access control on the server. Every sensitive action re-checked server-side, not just hidden in the UI. On Supabase, that means RLS on every table.
• Debug off in production. No verbose stack traces or debug endpoints leaking internals on an error page.
• Validated input and updated dependencies. Parameterised queries, validated inputs, no known-vulnerable packages.
• Rate limiting on login, signup, and anything expensive.

The quickest way to walk the code half is to make your AI tool review its own output against the list:

Do a pre-launch security review of my web app. Go through each item, tell me whether my project is affected, and give me the specific fix.

1. HTTPS: is HTTP redirected to HTTPS everywhere, and is HSTS set so browsers refuse to downgrade?
2. Secrets: are any API keys, tokens, or private keys committed to the repo or shipped in the client-side bundle? Which must move to server-side environment variables?
3. Access control: is every sensitive read and every mutation authorised on the server, not just hidden in the UI? If I use Supabase, is RLS enabled on every table with policies that restrict rows to the right user?
4. Input handling: are inputs validated and queries parameterised (no string-built SQL, no unescaped user input)?
5. Error handling: are debug mode and verbose stack traces off in production, so error pages don't leak internals?
6. Dependencies: any known-vulnerable packages I should update before launch?
7. Rate limiting: are login, signup, and expensive endpoints protected against abuse?

For each finding, give me the risk in one sentence and the exact change.

The item that isn't a launch task

Every check above is a snapshot — true the day you run it. But a valid certificate expires, a green site goes down, an endpoint starts erroring after a deploy. The last item on the list isn't something you tick once; it's ongoing.

Point a monitor at the site so the day something changes — the cert lapses, the URL stops answering — you hear about it before your users do. That's the difference between a checklist and staying secure after launch.