Website security audit — a practical checklist
Website security does not end with a certificate. Combine TLS, DNS, headers, email and network exposure into one prioritised assessment.
One check rarely shows the complete picture. A site can have a valid certificate but weak security headers, correct headers but broken DNS, or a hardened frontend beside an unnecessarily public admin panel.
A useful audit starts with an inventory and separates critical failures from hardening recommendations. Not every missing feature is a vulnerability, and every change must preserve application compatibility.
Domain and transport layer
Confirm DNS delegation, IPv4 and IPv6 addresses, certificate hostname and validity, and supported TLS protocols. Test the HTTP-to-HTTPS redirect and every public subdomain as separate endpoints.
- DNS and DNSSEC are consistent.
- The certificate covers the correct names and chain.
- HTTP redirects without loops to canonical HTTPS.
- No accidental service is exposed through unconfigured IPv6.
Headers, cookies and page resources
HSTS limits fallback to HTTP, CSP controls resource origins, and frame-ancestors or X-Frame-Options restricts embedding. Session cookies should use Secure, HttpOnly and an appropriate SameSite mode. Mixed content can weaken an otherwise encrypted page.
Email, ports and remediation priorities
A company domain also includes mail and public services. Review SPF, DKIM, DMARC, DNSBL results and open ports. Prioritise compromise, unprotected public panels, expired certificates and active mixed content before cosmetic recommendations.
- Assign an owner and deadline to every issue.
- Capture evidence before and after remediation.
- Repeat the audit after infrastructure changes.
- Enable alerts for controls that can regress over time.
Domain audit scope
- DNS, TLS and redirects.
- HTTP headers, cookies and mixed content.
- SPF, DKIM, DMARC and mail reputation.
- Open ports, public panels and change monitoring.
Put it into practice
Run a domain audit
Run coordinated DNS, TLS, HTTP, email and public-exposure checks in one report.
Run a domain auditFrequently asked questions
Does an automated audit replace a penetration test?
No. Automation is effective for configuration and exposure, but it does not fully assess business logic, authorisation or unusual application paths.
How often should a website be audited?
After significant deployments, DNS or hosting changes, and on a recurring schedule. Certificates, dependencies and public services can change without a site redesign.
Does a missing header always mean a vulnerability?
Not every header fits every application. Interpret the result in the context of the site's functionality and threat model.