Website Security
Website Security Checklist for Owners and Teams
A practical checklist for reducing visible website risk before launches, audits, campaigns, and customer reviews.
A checklist does not replace security engineering, but it helps teams avoid the common mistakes that repeatedly expose websites. It is especially useful before a launch, redesign, plugin update, hosting migration, or client handoff.
Use this checklist as a practical baseline. For websites with private accounts, payments, regulated data, or complex business logic, add authenticated testing and manual review.
Public website baseline
Start with controls that are visible from the outside. These checks catch configuration and deployment issues that are easy to miss during normal content work.
- HTTPS works on the main domain and important subdomains.
- HTTP redirects to HTTPS without unnecessary redirect chains.
- Canonical URLs are consistent and point to the intended public pages.
- robots.txt allows important public content and references sitemap.xml.
- sitemap.xml includes published public pages and excludes private app pages.
Browser and session hardening
Browser controls reduce the impact of common client-side mistakes. They are not a substitute for secure code, but they are part of a healthy website baseline.
- HSTS is enabled only after HTTPS is stable.
- Content-Security-Policy is tested and reflects the real script dependencies of the site.
- X-Frame-Options or CSP frame-ancestors protects sensitive pages from clickjacking.
- X-Content-Type-Options: nosniff is set.
- Referrer-Policy and Permissions-Policy are intentional.
- Session cookies use Secure, HttpOnly, and suitable SameSite attributes.
Access, updates, and backups
Operational controls matter because many attacks start with weak access, forgotten users, or outdated components rather than a novel exploit.
- Remove unused admin accounts and vendor users.
- Enable multi-factor authentication for CMS, hosting, DNS, email, payment, and analytics accounts.
- Patch CMS, plugins, themes, frameworks, runtimes, and server packages.
- Remove unused plugins and third-party scripts.
- Test backup restoration, not only backup creation.
- Document who owns security updates and incident response.
Scan, fix, and retest
A checklist is most valuable when it is tied to evidence. Run a scan, fix the highest-impact findings, and retest after deployment so the report reflects the current website.
- Prioritize confirmed issues affecting data, login, sessions, or access control.
- Review likely findings manually before treating them as proven.
- Track accepted risks with an owner and review date.
- Rerun scans after changes to headers, hosting, plugins, or authentication.
Recommended next steps
FAQ
Is this checklist enough for every website?
No. It is a strong baseline for public websites. Sites with accounts, payments, private data, or complex workflows need deeper authenticated and manual testing.
How often should I use the checklist?
Use it before launches and after meaningful changes, then repeat it on a schedule that matches the site's risk.
Should I fix every checklist item immediately?
Prioritize items that affect public exposure, sessions, customer data, login, and access control before lower-risk hardening tasks.
Turn the checklist into a real scan
Fixnx can check the public website baseline and turn findings into a readable report with evidence and next steps.