What gets measured gets improved. We shipped nine new security checks this month — some standard but missing from our own scanner, others that no public competitor runs. This post walks through each, why it matters, and how the EU benchmark numbers look so far.
Why the audit-expansion?
In early April we wrote a vs-comparison for five competitors — SSL Labs, Mozilla Observatory, securityheaders.com, Hardenize, Internet.nl — and promised a fact-based matrix of "what each tool checks." Writing that matrix honestly meant marking ourselves partial or no on checks our own scanner genuinely didn't run yet. That list became the roadmap.
Three weeks later, every one of those partial-marks is now a green. Here's what landed.
The Nine Checks
1. Nameserver redundancy (RFC 2182)
Every domain needs ≥2 nameservers on topologically distinct networks. Not "on the same cloud provider's two availability zones" — genuinely different networks, so an outage or BGP fumble takes out one but not both.
Our check groups each nameserver's IP addresses by /24 (IPv4) or /48 (IPv6) and fails when all NS share a single network. 1.2% of monitored domains flunk this — usually small operations running two NS on one VPS.
2. SOA serial consistency
Each authoritative nameserver serves its own copy of the zone. If one falls behind — stale secondary, broken AXFR, firewalled NOTIFY — your DNS replies become inconsistent depending on which NS the resolver hit. The SOA serial number is the canonical version marker; we query it from every NS and flag drift. Rare but catastrophic when it happens.
3. IPv6 readiness
Three AAAA-record checks rolled into one composite signal: - Web (apex / www) reachable via IPv6? - MX hosts reachable via IPv6? - Nameservers reachable via IPv6?
ok is True only when all applicable signals are True. Domains without MX records are scored "mail N/A" rather than failed — we don't penalise service-only domains.
NIS2 Art. 21(2)(c) lists business-continuity / modernisation among the required measures. Being reachable over IPv6 is part of that.
4. Subresource Integrity (SRI) on cross-origin <script> and <link>
Every external script your site loads is a supply-chain component. The 2018 British Airways breach happened because an attacker compromised a Modernizr CDN and added a skimmer to the minified file — which every baggage-checking browser duly executed.
SRI fixes this: <script src="…" integrity="sha384-…"> means the browser refuses to run a script whose hash doesn't match. Our new check counts the cross-origin <script> and stylesheet <link> tags on the rendered page, then tells you how many have an integrity= attribute. Missing SRI is a supply-chain risk that neither SSL Labs nor Hardenize scan for.
5. Mixed-content detection
An HTTPS page that loads an http:// image, script, or iframe is mixed content. Modern browsers either upgrade the request silently (sometimes) or block it (usually). Either way, it's a sign of a sloppy template migration from a legacy HTTP-first build. We parse the rendered HTML for any src=, href=, action=, data=, or poster= attribute that starts with http:// on a page served over https://. Capped at 20 URLs per scan.
6. TLS 1.3 0-RTT (early_data)
0-RTT is TLS 1.3's optimisation for resuming a session. Instead of waiting for the handshake, the client sends application data with its first packet. Fast — and replayable.
RFC 8446 §E.5 spells it out: 0-RTT data isn't forward-secret in the same way as a full handshake, and an active attacker can replay it. For idempotent GETs that might be OK. For POST /transfer-money it decidedly isn't.
We probe the server, parse Max Early Data from the OpenSSL handshake banner, and flag when 0-RTT is enabled. SSL Labs runs this. Hardenize runs this. Observatory doesn't. Ours does now.
7. HTTP/3 advertisement (Alt-Svc)
HTTP/3 runs over QUIC, and modern browsers only upgrade a connection to it when the server tells them to via the Alt-Svc: h3=":443" response header. No advertisement = your QUIC-capable server stays on HTTP/2 for every visitor. It's a performance + energy-efficiency gap that costs nothing to close.
None of the standard scanners check this — we noticed because we were writing the comparison page.
8. robots.txt / ads.txt integrity
Two info-disclosure checks tucked into one pass:
- robots.txt with long
Disallow:lists naming/admin,/backup,/.git,/staging— attackers use this as a map. We match against a 17-pattern list of commonly-leaked paths and report the count. - ads.txt (IAB spec) with zero valid entries — present-but-empty is worse than absent, because programmatic buyers treat it as "no authorised sellers" and ad-fraud bots exploit the gap. We parse the file and flag
empty_or_invalid.
9. security.txt quality (RFC 9116 §2.5.4)
Before this month our scanner only asked: does /.well-known/security.txt exist? Now we parse it properly:
- Multi-value
Contact:(RFC 9116 permits multiple — many scanners don't catch them). Expires:in the past invalidates the file per §2.5.4. An expired security.txt is worse than none — it signals a dead disclosure process to researchers.Canonical:URL must match the fetched host; otherwise we flag it.Encryption:,Policy:,Acknowledgments:,Preferred-Languages:recorded for completeness.
We found that ~14% of the security.txt files we'd seen marked "valid" in March were in fact expired. That's 14% of responsible-disclosure contacts that would silently fail. Fixed now.
Bonus: JARM drift detection (weekly)
Starting this week, every monitored domain gets a weekly TLS fingerprint probe via a lightweight implementation of Salesforce's JARM algorithm. The hash changes when:
- You switch server implementations (nginx → Caddy, AWS ALB → CloudFront)
- Your TLS policy shifts (cipher priorities, ALPN list)
- Someone puts a completely different server behind the same DNS
The third case is the interesting one — it's exactly how shadow-IT, account compromise, and mis-configurations surface. We store the hash, alert on change.
And because we cross-referenced against 75 known C2-framework JARM hashes (Cobalt Strike, Sliver, Metasploit, Brute Ratel, Mythic, AsyncRAT, Trickbot, …), a match is now a loud alert — not just "your TLS changed" but "your TLS looks like a C2 server."
That's an offensive check no competitor runs.
What it means for your grade
The scoring engine treats the new signals gently:
- Modernisation bonus (NS redundancy, SOA consistency, IPv6, HTTP/3) adds up to +6 points, capped at 100 so existing A-grades don't overflow. No one's grade drops because of this.
- Discovery-scan penalties (takeover, JARM C2) only apply to sites where we've confirmed the issue. If your weekly discovery scan comes back clean, you don't see a deduction.
Re-scan your site — the new rows will show up automatically.
Next up
Next on the roadmap, in roughly priority order:
- Certificate Transparency log monitoring (alert when a new cert for your domain gets issued — detects rogue issuance).
- BGP hijack indicators (AS-path anomalies for your hosting IP).
- DMARC rollout-readiness (gradient from p=none → quarantine → reject with policy maturity scoring).
If there's a check you wish our scanner ran, reply to this post or drop us a note — that's literally how this month's list got built.
— The SiteGuardian team