7 of the ten categories have purpose-built tests in SecQon. One is partial and two cannot be assessed by any external scanner. Most vendors publish a table of ten green ticks; that table is not true of anyone, and this page is the version we are willing to defend.
Readable source-control and configuration files, directory listing, CORS policies that permit a credentialed cross-origin read, API operations that answer without the authentication their own schema declares, state-changing forms with no CSRF token, and — on the full penetration test — path traversal, open redirect and object-level authorization (IDOR/BOLA) probes.
The TLS handshake itself: certificate trust, hostname coverage and expiry, and whether deprecated protocol versions (TLS 1.0 and 1.1) are still accepted — tested by actually offering them, not by reading a banner. Plus credentials submitted to plaintext http:// endpoints, and cookies missing Secure.
An inert marker through query strings and form bodies to observe unencoded reflection; on Deep, reflected XSS proved in a real browser and SQL injection confirmed by a boolean differential that reads no data; on the full penetration test, OS-command injection, server-side template injection, XXE, XPath and CRLF.
Not observable from outside — by us or by anyone. Insecure design is about the decisions behind an application, and no amount of traffic sent to a running system reveals them. Every report names this rather than leaving a gap that reads like a pass.
Browser-hardening headers and cookie flags on every page we reach, DNS and email-spoofing records (SPF, DMARC, CAA, DNSSEC), reachable services across a curated port list, database and framework error messages exposed in ordinary responses, and the misconfiguration template corpus.
The community template corpus, matched against the software your responses disclose. When that sweep does not complete, the report says the category was not assessed rather than reporting an empty result as a clean bill of health.
Reachable only through templates that recognise a service still answering on its shipped default credentials, plus cleartext credential paths and the CSRF-relevant cookie flags. This engine never submits a credential, so password policy, lockout and session management are not tested — and the report says so.
Third-party scripts executed without a Subresource Integrity hash, forms posting to another origin, publicly readable build and CI metadata, and — on the full penetration test — mass-assignment probes against your API's declared schema.
Whether you log the right events, keep them long enough, and alert on them is invisible from the outside. Nothing a host returns is evidence about it. Named on every report.
Confirmed out-of-band: we inject a callback URL and watch a collector we run. A server that calls us is undeniable proof, and it is invisible in the response — which is why this is a Deep-profile check, and why a report from a lighter scan states that SSRF was not assessed.
A report that stays silent about what it could not check is making a claim by omission — the reader assumes a category was assessed and found clean. Every SecQon report carries a “not assessed” table naming each category the scan did not reach and why. It is the same discipline that makes the findings worth trusting: we would rather tell you where we stopped than let you infer coverage we do not have.