Website security check before launch

SSL/TLS is configured correctly

Most launch checklists stop at “there’s a padlock in the address bar.” That’s not the same as correctly configured. Check that the certificate covers both the root domain and www, that HTTP actually redirects to HTTPS instead of just being available on both, and that the server isn’t still accepting old TLS versions. Mixed content — an HTTPS page that still loads one image or script over plain HTTP — is another common leftover from a rushed launch. Run the domain through the SSL certificate checker before you announce anything.

No exposed admin panels or default credentials left on

Staging and dev builds get thrown together with convenience logins — admin/admin, a shared password the whole team knows — with every intention of changing them before launch. Check the actual admin login URL and confirm the credentials were changed. Then check for a forgotten staging subdomain that’s still live, still indexed, and still running the same weak login as the version nobody meant to ship.

No debug mode or exposed .env / config files in production

Frameworks like Laravel, Django, Rails, and Next.js all have a debug mode that, left on, dumps stack traces, file paths, and sometimes environment variables straight into the browser the moment something errors. The same risk applies to files sitting in the web root that were never meant to be public — .env, .git/config, config.php. Try requesting yoursite.com/.env directly before launch. A 404 is what you want to see; actual file content is not.

Security headers are present

Headers like Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, and X-Content-Type-Options are a handful of lines in server config or middleware, and they close off a real chunk of common attack paths. Run the domain through the security headers checker before launch — it grades what’s missing in a few seconds.

DNS and email authentication records are set up correctly

Without SPF, DKIM, and DMARC records, your domain can be spoofed — someone else sends phishing email that appears to come from you. Missing or misconfigured records also mean your own legitimate mail is more likely to land in spam. While you’re in there, check for stale DNS entries too — an old A record pointing at a decommissioned server, or a subdomain you spun up for a demo and forgot to tear down. Run the domain through the DNS record lookup tool and compare what’s there against what should be there.

Forms have basic input validation

In plain terms: if a contact form, login field, or search box takes whatever a visitor types and hands it straight to a database query or a page render without checking it first, a visitor can type code instead of a name and have the server run it. Before launch, go through every form on the site and confirm the backend validates and sanitizes input server-side, not just with a JavaScript check that a request from outside the browser can skip entirely.

Backups exist and were tested to actually restore

A backup nobody has restored is a hope, not a backup. Confirm three things: backups run automatically on a schedule, they’re stored somewhere other than the same server they’re backing up, and someone has actually run a full restore at least once to prove the file isn’t corrupted or partial. This matters more in the first weeks after launch than at almost any other point.

A free automated scan and a manual audit aren’t competing options — they check different things, and a real launch checklist uses both.

• Automated checks cover the visible surface. SSL/TLS configuration, security headers, exposed files, DNS and email records, common misconfigurations — no login, no impact, results in under a minute.
• Logic flaws like IDOR need a human. Changing an order number or account ID in a URL and finding it shows someone else’s data is invisible to a scanner — it’s a flaw in how the application behaves, not a missing header.
• Broken access control and business logic bugs — a regular user reaching an admin-only action, or a discount code that can be applied twice — both fall in the same category as IDOR: findable by a person, not a signature match.

Finding these takes someone actually thinking like an attacker and trying things by hand, which is what a manual security audit is for — run before launch if there’s time, or in the first couple of weeks after if launch is imminent.