Website Security Checklist for Owners and Teams

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 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.

Operational controls matter because many attacks start with weak access, forgotten users, or outdated components rather than a novel exploit.

1. Remove unused admin accounts and vendor users.
2. Enable multi-factor authentication for CMS, hosting, DNS, email, payment, and analytics accounts.
3. Patch CMS, plugins, themes, frameworks, runtimes, and server packages.
4. Remove unused plugins and third-party scripts.
5. Test backup restoration, not only backup creation.
6. Document who owns security updates and incident response.

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.

Use this checklist as a practical pass before a launch, client handoff, remediation sprint, or recurring review. It focuses on evidence that can change decisions, not generic warnings.

• Start with public pages, headers, cookies, redirects, forms, files, and API surface.
• Separate confirmed evidence from likely signals and items that need manual review.
• Prioritize findings that expose data, weaken sessions, affect login, or reveal sensitive files.
• Use lower-severity hardening items after the highest-risk evidence is handled.
• Rerun a scan after changes and keep the updated report with release notes or client records.

A useful report should show what was observed, how risky it is, and what action would change the evidence on a retest.

• Issue: Missing browser security header
• Risk: Medium
• Evidence: A recommended browser protection header was not present on tested responses.
• Why it matters: Browser hardening does not replace secure code, but it can reduce common attack impact.
• Recommended fix: Add the missing header, test it on staging, deploy, and rescan to confirm the finding changed.

Do not treat every warning equally. Start with the findings that create the clearest public risk or the strongest evidence, then move into hardening and cleanup.

1. Critical exposed files, admin panels, secrets, or takeover paths.
2. Broken HTTPS, weak SSL/TLS, unsafe redirects, or insecure session cookies.
3. Confirmed injection, XSS, access-control, authentication, or sensitive API evidence.
4. High-impact browser protections such as CSP, HSTS, framing, and content-type controls.
5. Medium and low hardening recommendations after the risky public evidence is fixed.