What a website security audit should actually tell you.
A useful audit does more than check whether HTTPS is enabled. It should explain what is externally observable, distinguish evidence from assumptions, prioritise real weaknesses and provide a remediation path that can be verified.
Start with what the Internet can see.
An external audit examines the public attack surface without requiring privileged access. Typical controls include TLS and certificate configuration, HSTS, Content Security Policy, browser security headers, cookie flags, clickjacking protection, visible technologies and third-party scripts.
TLS & HTTPS
Protocol versions, certificate validity, forced HTTPS and transport security.
CSP & browser controls
Script execution policy, framing restrictions, MIME protection and permissions.
Visible technologies
Framework, CMS and server signals that can increase the attack surface when versions are exposed.
Data exposure
Public forms, scripts, APIs, uploads and other observable exposure signals.
Unknown is not the same as secure.
A non-intrusive audit cannot prove the security of source code, authentication logic, databases or internal networks. Likewise, absence of a visible WAF marker does not prove that no WAF exists. Good reporting must preserve that distinction and reduce confidence when a control is not observable rather than convert uncertainty into a false failure or a false pass.
DDoS readiness should be presented carefully.
A safe external assessment can evaluate DNS redundancy, CDN/WAF clues, caching, origin-offload signals, rate-limit signalling and a very small bounded sample of normal requests. It is not a volumetric DDoS test and cannot guarantee resistance to a real attack.
The value is in the verified correction.
The strongest workflow links each finding to a deterministic or assisted correction, validates the change in Preview/Staging where possible, rescans the site, compares before and after, and only then moves to production under the client’s approval rules.
Frameworks, agencies and high-security environments need context.
WordPress, proprietary CMS/AGL platforms, complex JavaScript frameworks, CDN/WAF products, authentication systems and regulated environments often require human review. Access to Git, staging, hosting controls and explicit change approvals becomes part of the security process itself.