Security work is the launch-checklist category most likely to get skipped, precisely because a misconfigured header or an open staging login doesn't cause any visible symptom — until it's exploited. None of the items below are exotic; they're mostly configuration, not custom development, and worth confirming as their own explicit pass rather than assuming they were handled somewhere upstream.
It's also worth treating this as a recurring check, not a one-time launch task — a header configuration can silently regress after a platform update, a plugin install, or a hosting migration, and a staging login someone re-enabled for a quick fix can easily get left open afterward. Re-running this checklist after any significant infrastructure change catches regressions before they sit exposed for months.
Security header checklist
- Content-Security-Policy (CSP) is set, restricting which domains scripts, styles, and other resources are allowed to load from — this is the primary defense against cross-site scripting (XSS) attacks.
- Strict-Transport-Security (HSTS) is set, so browsers only ever connect over HTTPS for the domain, even if a link or bookmark points to the HTTP version.
- X-Content-Type-Options: nosniff is set, preventing browsers from trying to guess and misinterpret a file's type in a way that can be exploited.
- Referrer-Policy is set to control how much of the current URL gets passed along as referrer data when a visitor clicks an outbound link.
- Headers are tested with a header-scanning tool after launch to confirm they're actually being served, not just configured in a file that isn't taking effect.
Access and credentials checklist
- All default credentials (from a CMS install, a hosting panel, a database) are changed — default logins are the single most automated attack vector on the internet, scanned for constantly by bots.
- Any staging-environment access (a shared password, an open test login) is removed or disabled once the production site is live.
- Admin login URLs and panels aren't left at obvious default paths without additional protection, where that's a realistic option for the platform in use.
- Two-factor authentication is enabled on every admin account where the platform supports it.
Form and traffic protection checklist
- Every public-facing form has spam protection — a honeypot field, a CAPTCHA, or both — to filter automated bot submissions.
- Rate limiting is in place on forms and login endpoints to slow down brute-force or scripted abuse.
- A basic firewall or WAF (web application firewall) layer — often available directly through the hosting provider or CDN — filters malicious traffic patterns before they reach the application itself.
| Item | Risk If Skipped | Effort to Fix |
|---|---|---|
| Default credentials left unchanged | Automated bots scan for and exploit these constantly | Very low — change on first login |
| Missing CSP/HSTS headers | Increased exposure to XSS and downgrade attacks | Low — configuration at the server or CDN level |
| No spam protection on forms | Bot-submitted junk data, inflated form metrics | Low — a honeypot field or CAPTCHA integration |
| Staging access left open | Unfinished or sensitive content exposed publicly | Low — remove or disable staging credentials at launch |
Most of this checklist is a one-time configuration pass, not ongoing maintenance — which makes it one of the highest-leverage items on a launch checklist relative to the effort involved. It fits into the same broader IT infrastructure foundation as monitoring, backups, and DNS/SSL, and is worth verifying together with those rather than treating security as a separate, optional pass.
FAQ
What security headers should every website have at launch?
At minimum: Content-Security-Policy (CSP) to restrict which sources scripts and resources can load from, Strict-Transport-Security (HSTS) to enforce HTTPS, X-Content-Type-Options: nosniff to stop browsers from misinterpreting file types, and Referrer-Policy to control what referrer data gets sent to other sites.
- These headers are configuration, not custom code, on most modern hosting platforms and CDNs.
- Test that headers are actually being served after launch — a header defined in a config file that isn't deployed correctly provides no real protection.
Why is a WAF necessary if the site already has SSL and secure hosting?
SSL protects data in transit and secure hosting protects the server itself, but neither stops application-layer attacks like bot traffic, credential-stuffing attempts on a login form, or basic exploit attempts targeting known software vulnerabilities — a web application firewall (WAF) filters that traffic before it ever reaches the application.
- SSL, secure hosting, and a WAF address three different layers of risk — none of them substitutes for the others.
- Many hosting providers and CDNs include a basic WAF layer as a built-in option, making this less effort to add than it sounds.