Two engines, two costs

The scanner runs two kinds of check, and the difference matters more than any count.

Active checks send requests. They inject a payload into a parameter, header or body and reason about what comes back — an error string, a time delay, a reflection, a changed status. They are how SQL injection, cross-site scripting, server-side request forgery and command injection get found. They cost traffic against the target and they are the checks an operator notices.

Passive checks send nothing. They read responses the application was already delivering — in the browser, through the proxy, during normal use — and look for what leaked: a stack trace, a private key, a session token in a URL, a missing security header, an overly broad CORS policy. Because they add no requests, passive checks can run continuously on every flow that passes through.

If you are assessing a production system on a budget of attention, passive first is the quiet, high-yield starting point.

What the active set covers

The active checks are grouped by the classes the industry already agrees on:

  • Injection — SQL injection (error, boolean, time and union based), command injection, server-side template injection, and template or expression injection in common frameworks.
  • Client-side — reflected and stored cross-site scripting, DOM sinks, and open redirects.
  • Server-side — SSRF, XML external entities, insecure deserialisation, and path traversal.
  • Protocol and parser — HTTP request smuggling, host header attacks, and content-type confusion.
  • Access control — broken object-level authorisation, broken function-level authorisation, and mass assignment.
  • GraphQL and WebSocket — introspection exposure, field-level authorisation gaps, and message-level injection.

Each check is registered in source with a lock-tested count, so the number on the website is derived from the code rather than typed by hand — the coverage figure cannot drift from what the binary actually runs.

Blind bugs need out-of-band

Some of the most valuable findings have no response to read. A server-side request forgery that fetches an internal URL, a command injection that runs but prints nothing, an XML entity that reads a file — all of these complete successfully while the attacker sees an ordinary page.

Out-of-band detection handles this by pointing the payload at a listener the tester controls and watching for the callback. Hugin's Oastify listener accepts interactions over DNS, HTTP, SMTP, LDAP, FTP and SMB, so a payload can exfiltrate through whichever protocol the target will actually emit.

Reading the numbers honestly

A coverage count is a count of check types implemented. It is not a claim that any particular target is vulnerable, and it is not a quality score. Two scanners with the same count can differ enormously in how well they detect a false positive or handle a WAF. What the count does tell you is breadth: which classes someone has written a check for, so you know where your manual testing effort is not wasted repeating work.

The honest test of a scanner is to point it at a system whose bugs you already know and see what it finds and what it misses. That is why the auth-bypass lab exists — a deliberately vulnerable target, with a known win, so coverage can be checked rather than trusted.