Website Security Checklist: 10 Things to Check Before Launch

Published December 20, 2025 · 8 min read

Website Security Checklist: 10 Things to Check Before Launch

I've launched enough sites to know that pre-launch excitement makes you forget things. Especially security things. So I keep this checklist and run through it every single time before hitting the big red deploy button.

Each item takes maybe 2-3 minutes to check. The whole list, maybe 20 minutes. That's nothing compared to the headache of dealing with a security incident on day one.

1. SSL is Actually Working

Sounds obvious. It's not. I've seen certificates that covered the domain but not the www version. Redirects that created infinite loops. Let's Encrypt certs that expired because the cron job silently failed.

Check these things:

• Your certificate is valid and not expiring in the next week
• Both www and non-www work (or one redirects properly)
• HTTP automatically redirects to HTTPS
• No "mixed content" warnings (HTTP stuff loaded on HTTPS pages)

Our SSL Checker catches all of this in 10 seconds.

2. Security Headers are Set

These take 5 minutes to add and block entire categories of attacks:

Check yours with our Security Audit. You want at least a B grade, ideally A.

On Cloudflare you can add most of these with a few clicks. On nginx or Apache it's a few lines in your config.

3. No API Keys in Your JavaScript

This is the one that keeps me up at night. I scan every site we audit and find exposed keys in roughly 1 out of 5. Stripe secret keys, AWS credentials, Firebase configs with no security rules... sitting right there in the public JavaScript bundle.

Scan your production site for:

• AKIA (AWS access keys)
• sk_live, sk_test (Stripe)
• sk- (OpenAI)
• ghp_, gho_ (GitHub tokens)
• Database connection strings

Our Secret Scanner checks for 212+ patterns. Or view-source and Ctrl+F for these patterns yourself.

4. Email Authentication is Configured

If you're sending any email from this domain - onboarding emails, password resets, newsletters - you need SPF, DKIM, and DMARC records.

Without them, two things happen:

Run your domain through DNS Health Check. If you're missing any of these, add them before launch. Gmail and Yahoo enforce these requirements now.

5. Debug Stuff is Gone

I've found live sites with /swagger exposing their entire API. /.git directories with full source code. /.env files with production credentials. /phpinfo.php showing server configuration.

Before launch, try accessing these URLs on your production site:

• /swagger, /api-docs, /graphql (should require auth or not exist)
• /.env, /.git, /config.json (should 404)
• /debug, /phpinfo.php, /server-info (definitely should 404)
• /actuator, /metrics (if you use Spring Boot)

If any of these work, fix your web server config to block them.

6. Admin Panel is Locked Down

Whatever admin interface you have - custom dashboard, WordPress admin, database GUI - it needs more than a password.

Check:

• Strong authentication (ideally 2FA)
• Rate limiting on login attempts
• No default credentials anywhere
• Admin path isn't guessable (maybe not literally /admin)

7. Dependencies are Updated

Run these commands before launch:

• npm audit (Node.js)
• pip-audit (Python)
• composer audit (PHP)

If you've got high or critical vulnerabilities, fix them. Yes, even if it means updating packages and testing again.

8. Input Validation Works

Every form, every URL parameter, every API endpoint that accepts user input - it all needs validation.

The big vulnerabilities to prevent:

• SQL injection (use parameterized queries)
• XSS (escape output, set CSP header)
• Command injection (never pass user input to shell commands)
• File upload exploits (validate types, don't trust file extensions)

9. Errors Don't Leak Info

Trigger some errors on your site. What do users see? If it's a stack trace with file paths, database queries, and framework versions, that's bad. Attackers use that information.

Production errors should show a friendly "something went wrong" message. The detailed info goes to your logs, not the browser.

10. Backups Actually Work

Not "I set up backups once" - I mean verify that you can actually restore from them.

Test it:

• Is the backup recent? (Check the timestamp)
• Can you access it if your server dies?
• Have you actually tried restoring to a test environment?

If you haven't tested a restore, you don't have backups. You have hope.

The 30-Second Pre-Launch Scan

Don't have 20 minutes? At minimum, run a Security Audit on your production URL. It checks SSL, DNS, headers, and exposed secrets automatically. Takes 30 seconds. If you're going to do only one thing, do that.

Frequently Asked Questions

If it's critical (exposed credentials, SQL injection), delay the launch. Everything else, document it, launch, and fix it within 48 hours.

After every deploy at minimum. I run a quick automated check on every PR merge.

If you're handling payments, health data, or anything sensitive - yes. For a blog or basic SaaS, this checklist plus automated scanning catches 90% of issues.