Three Server-Side Probes That Let Browser-Based Audits See Past the Browser

A browser-side audit tool can see a lot. Rendered HTML. HTTP response headers (minus the ones the CORS preflight hides). JavaScript runtime state. What it can't see from the browser: DNS records, TLS handshake internals, anything that needs a stable User-Agent, or the result of running the same request three times to check whether a finding is real or just a CDN-race transient.

Three small server-side probes, added to the site this week, fix all three gaps. They fortify the audit tools that already exist (Mega Security Analyzer, PQC Analyzer, DNS/Email Auth Audit, Security Headers Audit) without forcing anyone to install a desktop scanner.

probe-dns

The browser's request APIs can't issue a DNS query. DNS-over-HTTPS (DoH) is queryable from the browser, and the existing DNS Email Auth Audit does exactly that, but running it through a shared server-side probe gives three upgrades:

1. Retry + fallback. The probe queries Cloudflare DoH first, falls back to Google DoH if Cloudflare times out. Either endpoint can be down; both being down at the same time is rare.
2. Response normalization. DoH response shape is standardized but slightly different between providers. The probe normalizes to one structure.
3. Digest fields. Instead of handing raw records to every caller, the probe parses SPF, DMARC, DKIM, CAA out of the TXT responses and returns clean boolean flags plus the raw record. Every tool that consumes DNS gets the same parsed form.

Query: ?domain=example.com&type=DMARC. Returns JSON with both raw records and parsed digest.

probe-tls

The browser can't inspect a TLS handshake. The negotiated cipher, protocol version, certificate chain, OCSP stapling status, and hybrid-KEX support are all server-side information that only a server-side probe can read. Node's built-in tls module gives access to all of it, and exposes an option that lets the probe specifically request a post-quantum curve to test hybrid-KEX support.

The probe runs two handshakes against the target:

1. Standard handshake with default curves. Captures protocol, cipher, cert chain.
2. PQC handshake restricting the key-share to X25519MLKEM768 first, X25519Kyber768Draft00 as fallback. If handshake 2 succeeds, the server supports hybrid post-quantum key exchange. If handshake 2 fails, the server is classical-only.

Result includes days-until-expiry calc, issuer info, cipher standard name, and a PQC verdict.

revalidate

The false-positive-suppression probe. Many audit tools flag findings based on a single request. Caching layers, CDN shield races, rolling config deploys, and partially-warmed edges all produce single-request false positives.

Query: ?url=https://target&signal=missing_hsts&probes=3. The probe requests the target URL 3 times (configurable, 2-5), 700ms apart, and evaluates the specific signal against each response. Verdict:

• CONFIRMED if ≥ 2 of 3 requests see the issue.
• TRANSIENT if exactly 1 of 3 requests saw it. Treat as intermittent, not urgent.
• NOT_OBSERVED if 0 of 3 saw it. Downgrade the original fail to info; it was a false positive from the single-request scanner.

Supported signals: missing_hsts, missing_csp, xframe_missing, soft_404, canonical_to_404, meta_generator_wp, xmlrpc_reachable.

The signal set is deliberately small. Each signal needs a clear, deterministic pass/fail test. Adding signals is a matter of writing the evaluation function, not tuning thresholds.

What this fortification changes for users

Before: the audit reports a critical fail. User goes to fix it. User discovers the issue was already fixed two hours ago at the CDN layer, or never existed on the origin only on one edge node. User loses an afternoon.

After: the audit reports a finding labeled "revalidation: NOT_OBSERVED (0/3)" and downgrades it to info with a note that single-probe scanners would have flagged it. User reads the note, moves on, keeps their afternoon.

Across a typical scan, 10-20 percent of findings get downgraded or re-categorized by revalidation. Over a year of audits, that's days of wasted follow-up.

Why three probes instead of one

Each probe does one thing and does it well. The alternative would be a single monster endpoint that takes a mode= parameter, branches into TLS or DNS or revalidation paths, and becomes a maintenance nightmare. Three small focused probes stay readable, stay testable, and let each one cache independently (TLS probes cache for 5 minutes, DNS for 1 minute, revalidation for 30 seconds).

At normal audit traffic the three probes together fit well within standard hosting quotas.

Related reading

• Mega Security Analyzer, the tool that exercises all three probes in one scan
• PQC Analyzer, the PQC layer on its own
• DNS / Email Auth Audit, the DNS layer tool
• Security Headers Audit, the HTTP-headers layer tool

Fact-check notes and sources

• Cloudflare DoH endpoint documentation, https://developers.cloudflare.com/1.1.1.1/encrypted-dns/dns-over-https/
• Google Public DNS DoH documentation.
• Node.js tls module documentation (v22 LTS) for handshake internals.
• IETF draft-kwiatkowski-tls-ecdhe-mlkem for the hybrid-KEX spec.

This post is informational, not security-consulting, legal, or compliance advice. The probes run against publicly-served URLs only. Always respect target-site terms of service and rate-limit politely. Do not point any of these probes at third-party infrastructure you don't own without explicit written authorization.