Website security checklist

Security isn't a one-time setup step—it's an ongoing responsibility. This checklist covers the baseline every site should have, whether it's a simple brochure site or something handling customer data and payments.

HTTPS & SSL/TLS

• The entire site runs on HTTPS with a valid, non-expired certificate
• HTTP requests redirect to HTTPS automatically—there's no way to view the site insecurely
• Certificate configuration has been checked with a tool like Qualys SSL Labs' SSL Test for known weaknesses
• Certificate renewal is automated, or there's a reminder in place well before expiry

Security headers

• A Content-Security-Policy is configured to restrict what scripts and resources a page can load
• HTTP security headers (such as Strict-Transport-Security, X-Content-Type-Options and a sensible Referrer-Policy) are set
• Header configuration has been checked with a free scanner such as securityheaders.com

Software & dependencies

• The CMS, plugins, themes and any server software are kept updated with current security patches
• Unused plugins, themes and integrations are removed rather than left installed and unpatched
• Dependencies are sourced from reputable, actively maintained providers, not abandoned or unofficial sources
• Version numbers and stack details aren't unnecessarily exposed in page source or HTTP headers, which makes targeted attacks easier

Third-party & script security

• Every third-party script (analytics, chat widgets, ad tags, embeds) is treated as a real security consideration, not just a performance one—each one runs with access to the page
• Third-party scripts are loaded from the vendor's own domain, or via a mechanism that verifies the file hasn't been tampered with, where the platform supports it
• Scripts and integrations that are no longer actively used are removed rather than left connected indefinitely
• Any embedded forms or checkouts from third parties are confirmed to run over HTTPS with no mixed-content warnings

Backups

• Automated backups run on a regular schedule, covering both the database and files
• Backups are stored somewhere separate from the live server, not only on the same machine
• A restore has actually been tested at least once—an untested backup is not a verified backup
• There's a clear, documented process for who restores a backup and how, before it's ever needed under pressure
• Backup frequency matches how much data loss would actually be tolerable—a daily backup is not enough for a site taking constant transactions

Login & admin protection

• Admin and login areas use strong, unique passwords—never defaults left over from setup
• Multi-factor authentication is enabled for admin accounts wherever the platform supports it
• The number of people with administrator access is kept to the minimum actually needed
• Login attempts are rate-limited or otherwise protected against automated brute-force attempts
• Former employees' or contractors' access is revoked promptly when a project relationship ends

Forms & user input

• Contact and comment forms use spam protection so submissions don't become an unmanageable flood
• All user input is validated and sanitized server-side, not trusted just because it passed a client-side check
• File-upload fields, if present, restrict file types and size, and don't allow executable files

Environment & secrets management

• API keys, database credentials and other secrets are kept out of version control entirely—never committed, even temporarily, and never left in a public repository's history
• Different credentials are used for staging/development and production, so a leaked staging key can't touch live data
• Secrets are rotated after anyone with access to them leaves the project or if a leak is ever suspected, not left unchanged indefinitely
• Environment configuration is documented well enough that redeploying or rebuilding the site doesn't depend on one person's memory of which keys go where
• Third-party API keys are scoped to the minimum permissions they actually need, rather than granted broad access by default because it was easier to set up

Incident response

• There's a written plan for how to respond if the site is compromised—who to contact, how to restore from backup, how to rotate credentials
• Contact details for the host, DNS registrar and any critical vendors are documented somewhere accessible even if the site itself is down
• After any incident, a brief review captures what happened and what changes to prevent a repeat, rather than just restoring and moving on

Ongoing monitoring

• Uptime monitoring alerts you if the site goes down
• Security headers, SSL configuration and software versions are re-checked periodically, not only at launch
• Unusual admin activity (unexpected logins, unfamiliar new admin accounts, unexpected file changes) is something someone is actually watching for

See post-launch maintenance for how security tasks fit into an ongoing routine, privacy & cookie consent for handling personal data responsibly, and email deliverability for the DNS-level security that keeps your domain from being spoofed.