Skip to main content
Back to blog
April 28, 2026|9 min read

The Complete Website Security Audit Checklist for 2026

A practical, no-fluff website security audit checklist covering TLS, headers, cookies, DNS, email, privacy, and performance. Built for engineers who ship.

ZeriFlow Team

1,673 words

Most website security audits fall into one of two traps: a 200-page PDF that nobody reads, or a five-bullet checklist that misses everything that actually matters. This one is built for the middle ground — comprehensive enough to catch real issues, focused enough that an engineer can run through it in an afternoon.

A website security audit is the systematic review of every layer that touches your visitors: the TLS handshake, the response headers, the cookies you set, the DNS records that route traffic, the email infrastructure that signs your domain, the privacy posture you present, and the performance characteristics that affect both user experience and attack surface. Skipping any one of these leaves a gap an attacker can walk through.

This checklist covers seven domains and 40+ specific checks. For each domain we'll explain what to verify, which tools to use, and the red flags that should never make it to production. At the end, we'll show how to automate the whole thing so it runs on every deploy instead of once a year.

Check your site right now: Free ZeriFlow scan in 60 seconds →

Domain 1: TLS and Certificate Configuration

Your TLS configuration is the foundation. Get it wrong and nothing else matters.

What to check:

  • Certificate is valid, not expired, and issued by a trusted CA
  • Certificate covers all hostnames you serve (including www and any apex/subdomain combinations)
  • TLS 1.2 and 1.3 are enabled; TLS 1.0 and 1.1 are disabled
  • Cipher suites prefer AEAD ciphers (AES-GCM, ChaCha20-Poly1305) and forward secrecy (ECDHE)
  • HSTS header is present with max-age of at least 6 months and includeSubDomains
  • OCSP stapling is enabled to reduce handshake latency

Tools: SSL Labs, testssl.sh, ZeriFlow's TLS scanner.

Red flags: any TLS 1.0/1.1 support, RC4 or 3DES ciphers, missing HSTS, certificates expiring in under 30 days with no auto-renewal.

For a deeper dive into modern TLS configuration, see our TLS 1.3 migration guide.

Domain 2: HTTP Security Headers

Headers are free, take ten minutes to deploy, and stop entire classes of attacks. There's no excuse for missing them.

What to check:

  • Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • Content-Security-Policy: a real policy, not default-src * or report-only with no enforcement
  • X-Content-Type-Options: nosniff
  • X-Frame-Options: DENY or SAMEORIGIN (or use CSP frame-ancestors)
  • Referrer-Policy: strict-origin-when-cross-origin or stricter
  • Permissions-Policy to lock down camera, microphone, geolocation, payment APIs you don't use
  • Cross-Origin-Opener-Policy: same-origin for sensitive pages
  • Cross-Origin-Resource-Policy: same-site or stricter

Tools: SecurityHeaders.com, ZeriFlow, Mozilla Observatory.

Red flags: wildcard CSPs, unsafe-inline and unsafe-eval without nonces or hashes, missing HSTS on a production site, X-Frame-Options: ALLOWALL.

Domain 3: Cookies and Session Security

Cookies leak sessions when configured badly. The flags are well-known and trivial to set, yet half the sites we scan get them wrong.

What to check:

  • Secure flag on every cookie that touches authentication
  • HttpOnly on session cookies so JavaScript can't read them (XSS containment)
  • SameSite=Lax minimum, Strict where possible, None only with Secure and a documented reason
  • Reasonable Max-Age or Expires — long enough to be useful, short enough to limit blast radius
  • Domain scope is as narrow as possible (don't set cookies on .example.com if app.example.com is enough)
  • Path scope matches actual usage
  • Cookie names with __Host- or __Secure- prefix where applicable

Tools: browser DevTools, ZeriFlow cookie auditor.

Red flags: session cookies without Secure, OAuth tokens accessible via JavaScript, cookies set on parent domains by accident, cookies older than 1 year.

Domain 4: DNS and Domain Configuration

DNS is often the weakest link because it's owned by someone other than the engineering team. Audit it like any other production system.

What to check:

  • DNSSEC is enabled and validates correctly
  • CAA records restrict which CAs can issue certificates for your domain
  • No dangling CNAME records pointing to deleted cloud resources (subdomain takeover risk)
  • WHOIS privacy is enabled and registrar lock is active
  • TTLs are reasonable — short enough for fast failover, long enough to absorb traffic
  • No leftover staging or test subdomains pointing to abandoned infrastructure
  • Auto-renew on the domain itself is enabled

Tools: dig, dnsviz.net, ZeriFlow DNS scanner.

Red flags: missing DNSSEC, CNAMEs to deleted Heroku/S3/Azure resources, no registrar lock, expired domains in your portfolio.

Domain 5: Email Authentication

Your domain sends email even if you think it doesn't — password resets, transactional notifications, marketing. Without proper authentication, attackers can spoof you, and your real emails get filtered as spam.

What to check:

  • SPF record exists, is published correctly, and includes every legitimate sender
  • DKIM is enabled with at least 2048-bit keys, and selectors are rotated periodically
  • DMARC is published and set to p=quarantine or p=reject (not just p=none)
  • DMARC rua reports are being collected and reviewed
  • BIMI is set up if you've enforced DMARC and want logo display in inboxes
  • MTA-STS and TLS-RPT for inbound mail security

Tools: MXToolbox, dmarcian, ZeriFlow email security audit.

Red flags: SPF with +all, DMARC stuck on p=none for years, missing DKIM, no monitoring of DMARC reports.

Domain 6: Privacy and Data Handling

Privacy is now a security domain. GDPR, CCPA, and the 2024 EU AI Act all carry breach-level penalties, and "we didn't know what trackers our marketing team installed" is no longer a defence.

What to check:

  • A current privacy policy is linked in the footer of every page
  • Cookie consent is real (no pre-checked boxes, granular categories, easy to reject)
  • Trackers actually respect the consent state — no Google Analytics firing before opt-in
  • A data subject request endpoint exists and works
  • Third-party scripts are inventoried and reviewed
  • No personal data is leaked in URLs, referrers, or logs
  • TLS is enforced on every form that collects personal data

Tools: ZeriFlow privacy scan, Cookiebot, browser DevTools.

Red flags: Google Analytics or Meta Pixel firing pre-consent, missing privacy policy, third-party iframes that set cookies before consent.

Domain 7: Performance and Availability

Performance is security. A slow site is a denial-of-service in slow motion, and many performance issues hide actual security problems.

What to check:

  • TTFB under 600ms from major regions
  • Compression (gzip/Brotli) enabled on all text responses
  • HTTP/2 or HTTP/3 enabled
  • Cache headers are correct — public assets cached, sensitive responses marked no-store
  • Rate limiting on authentication and form endpoints
  • WAF or equivalent in front of public endpoints
  • Redirect chains kept to a single hop
  • Image and asset sizes within budget

Tools: WebPageTest, Lighthouse, ZeriFlow performance audit.

Red flags: 5+ second TTFB, no rate limits on /login, no compression, sensitive responses with Cache-Control: public.

How to Run This Audit Without Losing a Week

A manual run through this checklist takes a senior engineer roughly six to ten hours per site. That's not sustainable if you have multiple properties, frequent deploys, or any kind of regulatory cadence. Three approaches scale:

  1. 1Automate everything you can. ZeriFlow runs all 80+ checks across the seven domains in 60 seconds, gives you a prioritised report, and tracks changes over time. Use it on every deploy and every external-facing property.
  2. 2Schedule manual reviews quarterly. Some things — privacy policy accuracy, third-party contract review, incident response drills — need a human. Quarterly is enough for most teams.
  3. 3Add gates to CI. Run a security scan against your staging environment on every PR. Block merges that introduce regressions in the high-severity domains (TLS, headers, cookies).

For the headers piece specifically, our HTTP security headers guide walks through the production-ready configuration we recommend.

FAQ

Q: How long does a website security audit take?

A: A manual audit covering all seven domains takes 6-10 hours for a senior engineer. An automated scan with a tool like ZeriFlow takes 60 seconds and covers the technical 80%. The remaining 20% (privacy policy review, contract audits, incident drills) is best done quarterly with a human in the loop.

Q: How often should I run a security audit?

A: Automated scans on every deploy, comprehensive manual review quarterly, and a full third-party penetration test annually for any site handling regulated data. Most issues we find in audits are regressions introduced between scheduled reviews — automation closes that gap.

Q: Do I need a paid tool, or can I use free scanners?

A: Free scanners (SSL Labs, SecurityHeaders.com, MXToolbox) cover individual domains well but force you to stitch reports together by hand. A consolidated scanner like ZeriFlow saves you the integration work and tracks changes over time. ZeriFlow has a free tier that covers most small sites.

Q: What's the single most important domain to fix first?

A: TLS. A broken TLS configuration leaks every other layer. After that, the order is: HSTS and security headers, cookie flags, then DNS hygiene. Email authentication and privacy come next; performance last unless you're seeing actual outages.

Q: How do I prioritise findings from an audit?

A: Sort by exploitability and blast radius. A missing Secure flag on a session cookie is a real-world session hijacking risk and ships today. A missing Permissions-Policy is a hardening measure that buys defence in depth — important, but ship it next sprint. ZeriFlow scores findings on this exact axis.

Conclusion

A good website security audit is comprehensive, repeatable, and actually run. This checklist gives you the comprehensive part; automation gives you the repeatable part; calendar discipline gives you the actually-run part.

Don't try to do all 40+ checks manually every month. Run them once to establish a baseline, fix what's broken, and put automation in place so regressions surface on the day they happen instead of the day before your next compliance audit.

Start your free security scan on ZeriFlow → — all 80+ checks across the seven domains in this guide, in 60 seconds. Free plan available, no credit card required.

Ready to check your site?

Run a free security scan in 30 seconds.

Related articles

Keep reading