The Ultimate Website Security Audit Checklist for 2026

Website security isn't a one-time setup — it's an ongoing process. Whether you're running a personal blog or an e-commerce platform, this checklist covers the essential security measures every website should have in place in 2026.

SSL/TLS Configuration

An SSL certificate is table stakes, but proper configuration matters. Ensure you're using TLS 1.3, disable older protocols (TLS 1.0 and 1.1), configure HSTS (HTTP Strict Transport Security) with a minimum max-age of 31536000 seconds, and include your domain in the HSTS preload list.

Security Headers

Implement Content-Security-Policy to prevent XSS attacks, X-Content-Type-Options to prevent MIME sniffing, X-Frame-Options to prevent clickjacking, and Permissions-Policy to control browser feature access. These headers are free to implement and block entire categories of attacks.

Turning the checklist into a routine

A one time audit catches a snapshot of problems. A routine catches the ones that emerge between snapshots. Run the full checklist quarterly, then add a monthly lightweight pass that checks SSL certificate expiry, DNS configuration, third party script versions, and any new admin user creations. Most breaches in 2025 and 2026 traced back to a forgotten subdomain or an expired script source, not a sophisticated zero day. Routine beats heroism in this discipline almost every time.

Subdomain takeover remains a surprisingly common vector. Marketing teams spin up landing pages on Heroku, Vercel, or AWS, then forget to point the DNS away when the project sunsets. An attacker registers the same orphaned hostname and serves arbitrary content under your brand. Sweep your DNS records monthly using tools like Subjack or amass, and decommission anything not in active use. This is the easiest critical finding to fix and the most embarrassing one to ignore.

Content Security Policy headers are no longer optional. A strict CSP that allows only your own domain plus a tightly scoped list of analytics and font providers neutralizes the vast majority of cross site scripting attacks. Use a report only mode first to find legitimate violations, then promote to enforcement once your dashboards are clean. Reflected XSS still appears in scanner reports more often than it should, especially on sites built before 2020.

Dependency hygiene is the silent killer. A WordPress plugin abandoned by its maintainer can sit on your server for years collecting CVEs. Run npm audit, composer audit, or your stack's equivalent every week and triage anything marked high or critical immediately. Automated tools like Dependabot, Snyk, and Renovate make this nearly free. Pin your versions, review the changelog, and treat update PRs with the same seriousness as customer facing feature work.

Finally, plan for the incident you cannot prevent. Backups should be tested by actually restoring them on a staging environment, not just by trusting that the cron job wrote a file. Incident playbooks should name a specific person, not a role title. Keep an offline copy of your domain registrar credentials and DNS provider login somewhere outside your usual password manager. The first ninety minutes of a real incident are won or lost on preparation, not improvisation.

Authentication and session hygiene

Audit your login flow first, because that is where attackers spend most of their time. Confirm that all authentication endpoints are rate-limited at the edge, ideally with Cloudflare Turnstile, hCaptcha, or AWS WAF rules that block more than 5 failed attempts per IP per minute. Enforce account lockout with a delay rather than a hard count, since hard lockouts enable denial-of-service. Verify that session cookies set HttpOnly, Secure, and SameSite=Lax or Strict, and that the session lifetime is appropriate: 30 days for low-risk consumer apps, 8 hours for admin tools.

Move admin accounts off password-only authentication. Passkeys via WebAuthn are the cleanest option in 2026: every major browser supports them, and Authentik, Clerk, Auth0, and Stytch all ship managed passkey flows. Hardware tokens like YubiKey 5C NFC remain the gold standard for high-value accounts. SMS 2FA is broken often enough by SIM swapping that NIST formally deprecated it in SP 800-63B. Replace it with TOTP through 1Password, Authy, or Bitwarden, or push-based confirmation via Duo for SSO setups.

Dependency and supply-chain checks

Run npm audit, pip-audit, bundle-audit, or the equivalent for your stack in CI on every pull request. Block merges when high-severity CVEs land in production dependencies. Snyk, Dependabot, and Renovate handle the noisier parts of keeping things current. The harder problem is transitive dependencies and what they actually import at runtime. Tools like Socket.dev and StepSecurity flag suspicious package behavior such as a fresh maintainer suddenly adding a postinstall script. The XZ utils backdoor in 2024 was caught by a Microsoft engineer noticing a 500 millisecond delay on SSH login, which is the kind of weak signal worth investigating.

Generate a Software Bill of Materials for every release. Syft, CycloneDX, and SPDX formats are all widely supported. Store the SBOM alongside the build artifact in your container registry. When a CVE drops, you can answer in minutes whether your January build is affected rather than waiting for an emergency manual audit. For Docker images, run grype or Trivy on every push, fail builds on critical findings, and rebuild base images monthly even when nothing in your code changed. Stale base images are a quiet but constant source of vulnerabilities.

Backup and recovery validation

Backups that have never been restored are not backups. Schedule a full restore drill quarterly. For databases, that means provisioning a fresh instance, restoring the latest snapshot, and pointing a staging frontend at it to verify reads and writes work end to end. AWS RDS, Google Cloud SQL, and PlanetScale all support point-in-time recovery, but the documentation steps differ. Run through the playbook with a stopwatch, since recovery time objective matters as much as recovery point objective when an incident happens at 2 am on a Saturday.

Verify offsite immutability. The 3-2-1 rule still holds: three copies, two media types, one offsite, with at least one copy immutable via S3 Object Lock or a write-once-read-many tier. Ransomware operators routinely target backup volumes that share credentials with production. Use a separate account or service principal for backup storage, restrict deletion with MFA, and audit recently rotated keys. Test recovery from the immutable copy, not just the primary backup. The exercise is dull until you need it, at which point you will be glad you did it twice this year.

Secrets management and key rotation

Scan repositories for committed secrets with truffleHog, GitGuardian, or GitHub's built-in secret scanning. Beyond Git, scan container images and serverless function bundles, since people occasionally bake API keys into Lambda zip files. Move all production secrets into a managed store: AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, or 1Password Secrets Automation. Rotate keys quarterly for low-risk services and monthly for payment processors and admin databases. Pre-build the rotation runbook so the actual rotation is a 10-minute task, not a half-day archaeology project.

Audit who has access to secrets, not just whether they are encrypted. The principle of least privilege applies more strictly here than anywhere else. Engineers should access production secrets through short-lived credentials issued via IAM, not long-lived export files on laptops. AWS SSM Session Manager, Google IAP, and Tailscale SSH all give you auditable, expiring access without static credentials. Set alerts on secret reads from unusual IPs or outside business hours. Most secret leaks come from people, and the audit trail is where you catch them.

Logging, monitoring, and detection coverage

If you cannot answer who did what last Tuesday at 3 pm, your logging is not adequate. Centralize application logs in Datadog, New Relic, Loki, or CloudWatch with at least 90 days of retention. For authentication events specifically, keep 12 to 24 months so you can investigate slow-moving credential stuffing and account takeover attempts that span quarters. Pair logs with infrastructure metrics so you can correlate a CPU spike with a specific request pattern. Mean time to detection is the metric to track, and most teams measure it in hours when it should be in minutes for high-value endpoints.

Add runtime threat detection that watches for behavioral anomalies. CrowdStrike Falcon, Wazuh, and Falco for containers cover the common patterns: a webshell appearing in a wordpress upload directory, a process spawning a shell from a Node.js parent, or an unexpected outbound connection from a database server. Tie those alerts into Slack or PagerDuty with clear on-call ownership, and run a tabletop exercise every six months so the on-call rotation knows what to do without reading docs at 3 am. Detection without practiced response is theater.

Compliance overlap with your audit work

SOC 2, ISO 27001, HIPAA, and PCI DSS all expect annual security reviews with documented evidence. The audit work you do for security purposes can satisfy most of the operational controls if you keep evidence as a side effect. Vanta, Drata, Secureframe, and Thoropass automate evidence collection across AWS, GitHub, Okta, and a long list of SaaS vendors. They are not cheap at 12,000 to 50,000 dollars a year for small teams, but they cut audit prep from months to weeks and reduce repeated effort across frameworks.

Map each item on your audit checklist to specific control IDs in the frameworks you care about. CC6 in SOC 2 covers access controls. A.12 in ISO 27001 covers operations security. PCI DSS Requirement 6 covers secure development. Tagging your work this way means a single audit motion produces compliance artifacts for multiple frameworks. It also helps when a security questionnaire from a prospective customer lands, since you can answer with the actual control text rather than a hand-wave. Selling is easier when the security story is already documented.