A deep scan of docqon.com: 4.2 hours, 85,888 requests, nothing exploited

docqon.com is a sibling product built by Infiqon, the company behind SecQon. It is not a customer. We use it as our reference target because we own it, we know how it is built, and we can publish what we find. It is a largely static site served through Cloudflare, which matters for how the results below should be read.

A Deep scan is the Standard check set plus bounded exploitation, and it only runs after the owner acknowledges it for that scan. It starts by crawling the site in a headless Chromium browser, so a single-page application shows its real routes and API calls rather than one empty shell. On docqon.com, the crawl with a browser found 17 URLs, against 11 without one, including /app/, /api/auth/me and /api/config.

It then runs everything in Standard — security headers, TLS, DNS and email records, a curated list of 36 TCP ports, exposed files, API schema checks — and adds bounded exploitation stages — among them a reflected-markup check using an inert HTML element and a SQL-injection detection pass that reads no data — while the known-vulnerability sweep of roughly 7,000 safe templates runs across the URLs the crawl found, up to 35 per scan.

Every request goes through the scope guard, which checks the target against the verified-asset allowlist and pins the connection to the IP it authorised, at a ceiling of 10 requests per second per asset.

Our first production Deep scans of docqon.com on 12 September 2026 did not measure what they appeared to. The guard authorised 20,832 connections; the proxy behind it completed 1,252. The sweep found 5 raw template matches in production, against 82 when the same sweep ran from a laptop.

The cause was infrastructure, not the scanner: our cloud NAT gateway defaulted to 64 ports per instance, and a template sweep opens far more connections than that. Most were dropped before they left. The stage records still said the sweep had run. We raised the NAT port floor to 1,024, and the next scan returned the same 82 raw matches the laptop had.

We mention this because it is the kind of failure a customer cannot see: a scan that completes, reports findings, and has quietly tested a fraction of what it claims.

Later on 12 September the first full template sweep of docqon.com completed. It covered 14 URLs, sent 85,888 requests, and took 15,040 seconds — about 4.2 hours. That is roughly 6,100 requests per URL, at an average of under six requests per second — comfortably below the per-asset ceiling of 10. Requests over that ceiling are paced rather than dropped.

The sweep produced 214 raw template matches. After de-duplication they became 21 distinct findings.

We then ran it again. One run reached 99.6% of the planned work and the other 100%. They produced identical results: 0 new findings, 0 resolved, 21 unchanged. A scan that gives a different answer each time is not evidence of anything, so this was the result we cared about most.

This is also why we do not promise Deep results in minutes. A thorough sweep of a real site at a polite request rate takes hours.

The report of 13 September read "21 findings · 14 confirmed". It would be easy to read that as fourteen successful attacks. It was not. The fourteen were:

• 5 absent security headers.
• 2 accepted deprecated TLS versions (1.0 and 1.1).
• 3 DNS record facts.
• 4 reachable ports — 80, 443, 8080 and 8443 — all of them Cloudflare's edge, not docqon.com's own server.

In SecQon, "confirmed" means we went back and reproduced the condition: the header was still missing, the old TLS version was still accepted. Those fourteen were re-observed configuration facts. Both exploitation stages — the reflected-markup check and the SQL-injection detection pass — ran, and both came back negative.

The label invited a misreading, so we changed the report. There is now a separate, higher tier, "demonstrated", reserved for findings where a bounded proof of concept actually changed the application's behaviour. A clean host reads "0 demonstrated", which is what docqon.com gets.

An earlier Deep scan, on 30 August, had the same shape: 14 findings, all from the Standard checks, no false positives against a hand-built list of what was really there, and no exploitation stage finding anything. That report wrongly worded its conclusion as though exploitation had been proven. Reports now phrase exploitation claims from the stages that actually ran, never from the profile that was requested.

docqon.com's public surface is mostly static and sits behind a CDN, and the reflected-markup and SQL-injection stages found nothing to work with. A Deep scan of a site like that should find configuration issues and should not find exploits. If it had reported an exploit, the first thing to suspect would be the scanner.

The ports are a good example of reading results carefully. All four were genuinely reachable, and SecQon reports them. But they belong to Cloudflare's edge, and an early version of the explanation text told the reader "your server" had them open. The finding now says when a CDN fronts the host, and that the port belongs to the CDN's edge rather than the origin; the severity does not change.