The 30-Point Website Security Checklist (Launch-Ready in One Pass)
Thirty checks, one pass, zero fluff. This launch-ready checklist covers TLS, security headers, cookies, admin exposure, backups, DNS and email — each with the exact verification method.
📑 Table of contents
Security advice usually arrives as scattered tips. This checklist is designed to be worked top-to-bottom in one sitting — each item states what to verify and how. It mirrors what an external security scan checks automatically, so you can use the scanner as the fast path and this list as the deep path.
🔐 TLS & transport (points 1–6)
- HTTPS everywhere — no page, asset, or API endpoint may load over plain HTTP
- Valid certificate chain — full chain served, no missing intermediates, expiry > 30 days away
- Modern TLS versions only — TLS 1.2+; disable TLS 1.0/1.1 and SSLv3
- Strong ciphers — prefer AEAD suites; remove RC4, 3DES, and NULL ciphers
- HSTS enabled —
Strict-Transport-Security: max-age=31536000withincludeSubDomainsonce you are confident - No mixed content — every subresource on an HTTPS page must itself be HTTPS; our mixed content guide covers the subtle cases
📋 Security headers (points 7–12)
- Content-Security-Policy — the single most powerful XSS mitigation; start with
default-src 'self'and loosen deliberately - X-Content-Type-Options: nosniff — stops MIME-type sniffing attacks
- X-Frame-Options / frame-ancestors — prevents clickjacking; details in our clickjacking and CORS explainer
- Referrer-Policy —
strict-origin-when-cross-originis the sensible default - Permissions-Policy — disable browser APIs your site never uses (geolocation, camera, microphone)
- Server banner minimization — do not advertise exact server and framework versions where avoidable; see our stack trace disclosure article for why version details help attackers
🍪 Cookies & sessions (points 13–16)
HttpOnlyon session cookies — keeps JavaScript from reading them (XSS damage control)Secureflag everywhere — cookies must never travel over HTTPSameSite=LaxorStrict— modern CSRF defense at the cookie level- Session lifecycle — regenerate IDs at login, short idle timeouts, server-side invalidation at logout
🚪 Access & admin exposure (points 17–21)
- No default credentials — anything with admin rights gets a unique, long password
- Admin paths not guessable —
/adminon the public site is a brute-force magnet; hidden paths and their discovery are covered in our recon-oriented posts - Two-factor authentication — on the CMS, the hosting panel, and DNS registrar at minimum
- Login rate limiting — throttle repeated failures; lockouts notify an admin
- Account enumeration closed — identical messages for wrong-user and wrong-password
🧩 Code & dependencies (points 22–25)
- Input validation server-side — client validation is UX, not security
- File uploads hardened — validate type server-side, store outside the webroot or block execution
- Dependencies current — subscribe to advisories; our supply chain dependencies piece explains OSV-based checking
- Error handling safe — custom error pages; never leak stack traces to visitors
🌐 DNS, email & infrastructure (points 26–30)
- SPF, DKIM, DMARC — all three, with DMARC monitoring; our SPF/DKIM/DMARC guide walks the setup
- No dangling DNS records — stale CNAMEs pointing at deleted services are takeover fuel; see subdomain takeover
- Registrar lock + transfer PIN — domain hijacking is a one-way disaster
- Backups tested — 3-2-1 rule, and at least one restore actually rehearsed
- Continuous scanning enabled — a checklist protects the day you run it; scheduled scans protect every day after; our continuous monitoring page explains the setup
Using this checklist efficiently
Working all 30 points manually takes hours. A structured division of labor looks like this:
- ⚡ Automated first — points 1–12, 24, 26–27 are fully scanner-checkable
- 👀 Manual review — points 13–21 depend on your application's specifics
- 📆 Calendar-driven — points 25, 29, 30 belong to a recurring schedule
Run a free scan, fix what it flags, then walk the manual section with your developer. Re-run the scan before launch, and schedule it weekly after. That single habit converts this checklist from a one-time project into standing protection.
Security research and engineering at 2MNY — the team behind 282 free website-security scanners and the open-source Website Vulnerability Scanner. We find exposed secrets, misconfigurations and real vulnerabilities, then explain how to fix them in plain language.
1 What should a website security checklist include?
At minimum: TLS configuration, HTTP security headers, cookie flags, admin access protection, input validation, file upload handling, dependency patching, backups, DNS hygiene, and email authentication (SPF, DKIM, DMARC).
2 How often should I run through a security checklist?
Run the full checklist before every major launch and after every significant change, and automate the continuously checkable items — headers, TLS, exposed files, software versions — with scheduled security scans.
3 Which security headers matter most?
Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options or the CSP frame-ancestors directive, and Referrer-Policy form the core set.
