Launch-day security work is almost always the same handful of items, and almost always done in a hurry after someone asks whether the site is safe. Running through them deliberately takes under an hour and removes the class of problem that gets found by automated scanners trawling the internet within days of a new domain going live.
This is a pre-launch list, not a penetration test. It covers the configuration mistakes that are cheap to fix before launch and awkward afterwards.
1. Transport
- HTTPS available and serving a valid certificate covering every hostname you use, including www and any subdomain.
- Plain HTTP redirects to HTTPS with a 301, on every path — not just the homepage.
- TLS 1.2 minimum, 1.3 enabled. Deprecated versions disabled.
- HSTS set, with a sensible max-age. Consider preload only once you are certain every subdomain can serve HTTPS.
- Certificate renewal automated and the renewal tested, not just configured.
2. Response headers
The highest ratio of protection to effort on this list. At minimum:
- Content-Security-Policy - Restricts where scripts and other resources may load from
- X-Content-Type-Options: nosniff - Stops MIME-type guessing
- X-Frame-Options - or CSP
- frame-ancestors - Prevents clickjacking
- Referrer-Policy - Limits what leaks in the Referer header
- Permissions-Policy - Turns off browser features you do not use
CSP is the one people skip because it breaks things. Start in report-only mode, collect violations for a week of real traffic, then enforce.
3. Cookies
Every cookie that carries session state needs Secure, HttpOnly and an explicit SameSite. Check what your framework sets by default rather than assuming — defaults vary between versions and several frameworks changed theirs in the last few years.
4. Information disclosure
Turn off the headers that announce your stack: Server version strings, X-Powered-By , framework generator meta tags. This is not a vulnerability on its own; it is free reconnaissance for anyone scanning for a known CVE in a specific version.
Then check what is reachable that should not be. Source control directories, environment files, backup archives, build artefacts, database dumps, editor swap files and phpinfo pages are all routinely found on production hosts by automated crawlers. Verifying this from the outside takes seconds with a website vulnerability scanner, and the outside view is the one that matters — what your deploy config intends and what the web server actually serves are frequently different things.
5. Front-end dependencies
- No JavaScript libraries with known vulnerabilities. Check the versions you ship, not the versions in your lockfile.
- Subresource integrity on anything loaded from a third-party CDN.
- No mixed content — one HTTP image on an HTTPS page is enough to trigger browser warnings.
- An inventory of every external script. Each one is a party that can execute code on your users' behalf.
6. Application basics
Beyond configuration, the four that account for most real incidents in small applications:
- Parameterised queries everywhere. No string concatenation into SQL, no exceptions.
- Output encoding by context. HTML, attribute, JavaScript and URL contexts each need different escaping.
- Authorisation checked server-side on every request. Hiding a button is not access control.
- Rate limiting on login, password reset and anything that sends email.
7. Operational
Debug mode off. Stack traces not shown to users. Default and seeded credentials removed. Admin interfaces either restricted by network or protected with multi-factor authentication. Logging on, and going somewhere you will actually look. Backups taken and, at least once, restored.
Re-run it after launch
Configuration drifts. A CDN change, a framework upgrade or a new third-party script can quietly undo any of the above, so schedule the same checklist monthly rather than treating it as a launch-day ritual. It takes ten minutes once the first pass is done, and it catches the regression before someone else does.
