How to audit a website for security (2026 guide + free checklist)

Why public-signal security matters more than founders think

A pen test costs $5,000-$50,000 and you can't run one until you're funded. The public-signal layer is where most preventable breaches start: missing HSTS, forgeable email, exposed admin panels, source maps in production. None of that requires a pen test to find. All of it requires fixing before you hire anyone.

Public-signal security is also the layer that AI-driven reconnaissance scans first. Automated security scanners - used by both red teams and opportunistic attackers - look at exactly the signals below before deciding whether a site is worth investigating further. Strong public signals don't make you bulletproof, but they make you boring, and boring sites get skipped.

The 9 signals

1. HTTPS + HSTS - the actual front door

If your site loads on http:// without redirecting, you fail. If it redirects but doesn't set HSTS, your visitors are vulnerable to anyone running a Wi-Fi MITM attack at a café.

What to check:

• Open http://yoursite.com (not https) - does it redirect to https with a 301?
• Inspect the response headers on https://yoursite.com. Look for Strict-Transport-Security.
• The HSTS header should have max-age=31536000 (one year) or more, includeSubDomains, and ideally preload - then submit to the HSTS preload list.

What most tools miss: they check for HSTS presence. They don't check whether max-age is high enough to qualify for the browser HSTS preload list (6 months minimum, 2 years for production), or whether includeSubDomains is set. A misconfigured HSTS is almost worse than none - it doesn't get you into the preload list and gives a false sense of security.

2. Modern security headers - beyond X-Frame-Options

X-Frame-Options is the 2010s header. In 2024-2026, you want the newer set, documented in the OWASP Secure Headers Project:

• Content-Security-Policy - restrict what scripts/styles can load. Modern CSP uses 'strict-dynamic' + nonces, not host allowlists.
• frame-ancestors in CSP - replaces X-Frame-Options.
• Cross-Origin-Opener-Policy (COOP) - isolates your origin so Spectre-class attacks can't read cross-origin memory.
• Cross-Origin-Embedder-Policy (COEP) - required if you use SharedArrayBuffer.
• Permissions-Policy - disable APIs you don't use (camera, microphone, geolocation, payment).
• Referrer-Policy: strict-origin-when-cross-origin - don't leak full URLs to third parties.

What to check: open your site in DevTools → Network → click the document request → Response Headers. Confirm CSP exists and doesn't just say default-src * (which is no CSP at all).

What most tools miss: they treat CSP as binary present/absent. The actual question is "is the CSP strict enough to block injection?" A permissive CSP is a false positive in most security tools.

3. Email authentication - SPF, DMARC, DKIM

If you don't have a p=reject DMARC policy, anyone can send email from your domain. The phishing risk is significant; the regulatory expectation (Google and Yahoo enforce this for senders >5,000 emails/day since Feb 2024) is unambiguous.

What to check (run these as DNS lookups):

• dig TXT yourdomain.com → look for v=spf1 ... -all (the -all means hard fail; ~all is soft fail and weaker)
• dig TXT _dmarc.yourdomain.com → look for v=DMARC1; p=reject; ... (p=none = monitoring only; p=quarantine = better; p=reject = strongest)
• Confirm rua=mailto:... is set so you get aggregate reports
• DKIM is harder to verify without a selector - but a DMARC report tells you whether DKIM is signing correctly

What most tools miss: they flag missing SPF but don't check the lookup count. RFC 7208 caps SPF at 10 DNS lookups; many SPF records (especially after years of "add a vendor here") exceed this and silently break. The result: legitimate email starts getting rejected even though SPF "exists". If your site also ships marketing pixels, this is exactly the kind of overlap covered in the privacy audit guide - a single third-party adds both privacy and security surface.

4. DNS hygiene - DNSSEC, CAA, MTA-STS, TLS-RPT

The DNS layer is where most small-business sites have zero defense in depth.

• DNSSEC - signed DNS records. Without it, your DNS responses are forgeable.
• CAA records - 0 issue "letsencrypt.org" says only Let's Encrypt can issue certs for your domain. Stops a rogue CA being tricked into issuing a cert for you.
• MTA-STS - /.well-known/mta-sts.txt + _mta-sts.<domain> TXT record. Enforces SMTP TLS so email can't be downgraded to plaintext.
• TLS-RPT - _smtp._tls.<domain> TXT record. Get reported when TLS fails on inbound email.

What to check: run dig DNSKEY yourdomain.com (DNSSEC) and dig CAA yourdomain.com. Then visit https://yourdomain.com/.well-known/mta-sts.txt - should return a policy file.

What most tools miss: all four. DNSSEC + CAA + MTA-STS + TLS-RPT are the email-and-DNS hygiene tier. Standard SEO audit tools never look here.

5. Cookie security - Secure, HttpOnly, SameSite, prefixes

Modern cookie security is about what attributes are set, not just whether cookies exist.

What to check: open DevTools → Application → Cookies. For each cookie:

• Secure - only sent over HTTPS (mandatory in 2026)
• HttpOnly - not readable from JavaScript (XSS protection)
• SameSite=Lax (default for most cookies) or SameSite=Strict (for session cookies after login)
• Session cookies for authenticated areas should use __Host- prefix - locks the cookie to a single domain, no Path issues
• Consider Partitioned attribute (CHIPS - Cookies Having Independent Partitioned State) for third-party context cookies

What most tools miss: the prefix and Partitioned attribute checks. These are 2024-2026 cookie hygiene that's barely shown up in audit tooling.

6. Information exposure - Server header, generator meta, source maps, robots.txt

The classics. Most sites leak more than they realize.

What to check:

• Server header in response - does it say Apache/2.4.41 (Ubuntu) or nginx/1.18.0? That's a version string an attacker can match to known CVEs. Strip it or generic it.
• X-Powered-By header - should not exist.
• <meta name="generator"> in HTML source - does it say WordPress 6.2.1? That's a CVE lookup waiting to happen.
• .map files in production - open https://yoursite.com/static/js/main.js.map. If it loads, you're shipping your source code to anyone who looks. Block these via deploy config.
• robots.txt - does it disallow /admin, /wp-admin, /staging, /test? Disallowing tells an attacker exactly where to look. Either don't have them, or set them to noindex via meta but not robots.txt.

What most tools miss: the .map file check. Source maps in production are a depressingly common leak that almost no SEO-focused audit tool surfaces. Build-output hygiene like this also shows up in the technical-health audit guide - same cause, different consequence.

7. Third-party scripts + Subresource Integrity

Every third-party script is a supply-chain risk. The Magecart attacks against British Airways (£20M ICO fine, 2020) started with one injected line in a third-party script. Once you've added a <script src="https://anything.com/...">, you've trusted that vendor to ship malware-free code forever.

What to check:

• Count your third-party <script> tags. Five is fine; fifty isn't.
• Each should have either:
  • integrity="sha384-..." (Subresource Integrity hash) so the browser refuses to execute if the file changes, OR
  • A crossorigin + first-party load via your CDN

What most tools miss: SRI coverage as a percentage. Sites with 30 third-party scripts and zero SRI hashes are common.

8. CMS + dependency CVE exposure

If your <meta name="generator"> says WordPress 6.4.2, an attacker looks up the NIST National Vulnerability Database and finds the public exploits for 6.4.2. This is how most SMB sites get compromised.

What to check:

• Generator meta - exists and shows a version? Strip it.
• Robots.txt or theme paths leaking /wp-content/themes/oldtheme/style.css?ver=1.2? That ?ver= is a version string for an old theme.
• jQuery version - <script src="...jquery-1.11.3.min.js"> is a 9-year-old jQuery with known XSS vulnerabilities. Audit and upgrade.

What most tools miss: they check the CMS version but don't cross-reference with the NVD. AuditHQ does - the Security suite fetches NVD CVEs for detected CMS versions and surfaces the actual exploits an attacker would find.

9. /.well-known/security.txt - the maturity signal

A security.txt file at https://yourdomain.com/.well-known/security.txt is a one-line declaration that you take security seriously. Researchers who find vulnerabilities use it to know how to report. Auditors use it as a maturity signal. The format is standardised in RFC 9116:

Contact: mailto:security@yourdomain.com
Expires: 2027-12-31T23:59:59Z
Encryption: https://yourdomain.com/.well-known/pgp-key.txt
Acknowledgments: https://yourdomain.com/security-thanks
Preferred-Languages: en

What most tools miss: the Expires check. A stale Expires (past date) is treated as no security.txt at all by most parsers.

Worked example: a real audit on a real SMB

A small Australian service business we audited recently. The site is well-built and Cloudflare-fronted - but the security audit surfaced specific, fixable gaps. Anonymised findings:

• HTTPS + HSTS: HTTPS enforced. HSTS present with max-age=31536000; includeSubDomains - but missing preload, which means the site isn't on the browser HSTS preload list. The first visit on a new device is still vulnerable to HTTP downgrade.
• Security headers: Only 2 of 5 modern headers present. Content-Security-Policy, X-Frame-Options, Permissions-Policy all completely absent. The site can be clickjacked (embedded inside a malicious frame) and has no XSS mitigation beyond the browser default.
• Email authentication: The worst category - score 5/100. No SPF record at all. No DMARC record. Anyone on the internet can send email pretending to be from the domain and most providers will deliver it. For a service business that emails clients about appointments and payments, this is the actively exploited risk in 2024-2026.
• DNS hygiene: No DNSSEC. No CAA. No MTA-STS. No TLS-RPT.
• Cookie security: Mixed. Site uses Cloudflare default cookies (good). Session cookies have basic flags but not __Host- prefix.
• Information exposure: Strong - no Server version leak, no source maps in production, no generator meta. The build pipeline doesn't expose version strings.
• Third-party scripts + SRI: 2 external scripts (Google Tag Manager, Flock Analytics). Zero SRI coverage. Reputable providers, but if either is ever compromised, the malicious code runs unchallenged.
• CMS exposure: Not applicable - custom Vite/React build, no CMS to exploit. Significant strength.
• security.txt: Absent.

Composite score: 52/100, Grade D. The fixes are mostly DNS-record additions and header config - about 4 hours of work end-to-end. Setting DMARC p=none (monitoring mode), adding SPF, and rolling out CSP would lift the score from D to B in a week, with the biggest single move being killing the email-spoofing risk.

These are examples of findings an AuditHQ Security review can surface. Real evidence per finding, not generic checklists. The same business also showed up in the reputation audit guide at 28/F - a pattern worth understanding: strong work, weak visible infrastructure.

Run it on your site automatically

Most of what's above is one-line config changes on Cloudflare, Vercel, or your nginx file. The hard part is knowing what to check and in what order. The AuditHQ Security suite reviews public security signals and shows the evidence behind observed findings, such as header values, DNS records, and visible CMS versions.

FAQ

Written by Adam Savage, Founder of AuditHQ - 17 years building digital products. Last updated 13 May 2026.