HolicSecurity · Guide
What a passive website security audit checks
Published 31 October 2026
In short: a passive audit looks only at what your site already shows anyone on the internet: its TLS setup, response headers, page source, a handful of well-known file paths and public DNS records. It never attacks, guesses passwords or logs in. Below is every check in a HolicSecurity audit, exactly as our tool runs it.
Before anything: ownership
We only audit a site after its owner confirms they're authorised and proves control of the domain, with a DNS TXT record (holicaudit-verify=<token>) or a file at /.well-known/holicaudit.txt. Our tool refuses to start until it finds the token. If you can't verify, we refund in full and send nothing to your site.
The checks, one by one
1. TLS and certificate
Which protocol versions the server accepts (TLS 1.0 and 1.1 should be refused; 1.2 and 1.3 accepted), whether the certificate chain validates, and how many days until it expires.
2. HTTP to HTTPS redirect
Whether a plain http:// request is redirected to HTTPS, and whether your domain is on the browsers' HSTS preload list (looked up on hstspreload.org).
3. Security headers
Content-Security-Policy (and its report-only version), Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-, Resource- and Embedder-Policy, and CORS headers. Our guide Security headers explained covers what each one does.
4. Cookies
Whether cookies the site sets carry the Secure, HttpOnly and SameSite flags.
5. Page content
Mixed content (anything loaded over http:// on an HTTPS page), third-party scripts and whether they use Subresource Integrity, and whether the homepage is an auto-generated directory listing.
6. Software versions and known CVEs
Versions your site announces publicly: headers such as Server, X-Powered-By and X-Generator, the HTML generator tag, JavaScript library file names (jQuery, Bootstrap, Lodash, Moment, Angular, Vue, React and others), and the version banner in the first 2 KB of same-site scripts. Each version is looked up in the public OSV.dev and NVD databases. A match is reported as "version X is listed as affected by CVE-Y; confirm with the vendor", because patches can be backported and a listed version isn't proof the site can be exploited. We never test exploitability.
7. Exposed files
A fixed list of 7 well-known files that should never be public:
| Path | Why it matters if it's public |
|---|---|
/.git/HEAD | Can let anyone rebuild your source code and history |
/.env | Often holds database passwords and API keys |
/wp-config.php.bak | A WordPress config backup, including database credentials |
/server-status | Apache status page that shows live requests and client IPs |
/phpinfo.php | Lists server configuration, paths and versions |
/.DS_Store | A macOS file that lists the names of files in a folder |
/backup.zip | A full site backup left in the web root |
We first request a random path to learn what your "not found" page looks like, so a custom 404 isn't mistaken for a real file. For each path we read at most 256 bytes, compare them with a known file signature, and record only yes or no. We never download or keep the contents.
8. robots.txt and security.txt
We respect your robots.txt, and check whether you publish /.well-known/security.txt, which tells researchers how to report a vulnerability to you.
9. Email and DNS
SPF and DMARC (can someone send email pretending to be you?), DKIM on 13 common selector names, CAA (which certificate authorities may issue for your domain) and DNSSEC. All are public DNS lookups through Google Public DNS, which send nothing to your server. DKIM can only be tested on common selector names, so "not found" doesn't prove it's missing.
10. Forgotten subdomains (Plus tier)
Hostnames listed for your domain in public certificate-transparency logs. We list them so forgotten subdomains turn up, but we don't scan any that you haven't verified.
What a passive audit never does
- Exploit anything, send attack payloads or try to prove a vulnerability by using it
- Guess passwords, try logins or test authenticated areas
- Fuzz, brute-force directories or run aggressive scanner modes
- Send high request rates: we stay under one request per second and identify ourselves as
HolicSecurity-PassiveAudit/1.0 - Audit a site whose owner hasn't authorised it, including competitors
For scale: the audit in our sample report, of our own sister site, used 14 HTTP requests and 5 TLS handshakes in total. Every request is printed in the report.
Limits: what it can't see
A passive audit sees what the internet sees. It can't see software that hides its version, bugs in your application's logic, anything behind a login, or your server's internals. A clean result means our checks found nothing, not that the site is secure. Every report says so and lists what wasn't tested.
Passive audit or penetration test?
A penetration test has a person actively try to break in, usually over days, and costs far more. A passive audit is a fast, low-cost first pass that catches the common, easy-to-fix exposures: missing headers, leaked files, outdated libraries and email spoofing gaps. For a small business site, a blog or a SaaS landing page, it's often the right place to start. For a high-risk application that handles payments or sensitive data, it doesn't replace a professional pentest.
See the three audit tiers and prices, or read the full sample report first.