How it works, in enough detail to judge it
Most security tools describe their method in adjectives. Here is ours in steps, with the limits stated — because a claim you cannot check is not worth much when the subject is whether your application is safe.
- 01
You prove you own the asset
Nothing is scanned until ownership is verified — a DNS TXT record, a hosted file, or a meta tag for a domain; a hosted token for an IP. An asset in any other state never receives a single packet. This is not a formality: it is the difference between a security tool and an attack, and it is enforced in the code rather than promised in a policy.
- 02
We map what is actually there
Passive discovery reads certificate transparency logs and passive-DNS aggregators to suggest subdomains you may have forgotten — it never touches them; you decide what to add. On a Deep scan a headless browser crawls the asset, so a React or Vue application presents its real routes and API calls rather than one empty shell.
- 03
We test, inside a hard boundary
Every outbound packet is checked against your verified-asset allowlist and pinned to the IP that was authorised, at the moment it is sent. A hostname that appears mid-scan cannot widen the scope, and a DNS answer that changes between the check and the connection cannot redirect us. Rate limits and scan windows are enforced at the same boundary.
- 04
Every candidate is re-tested before you see it
This is the step most scanners skip. A finding does not reach your report on the strength of the tool that produced it — it is re-tested against your live asset, and only a reproduction earns the word ‘confirmed’. Where a re-test cannot run, the finding says so instead of borrowing confidence it did not earn.
- 05
You get a report that says what we did — and what we did not
Plain-language impact, step-by-step remediation, and the evidence behind every claim. The report also names every category the scan could not assess, and why. A scanner that is silent about its blind spots is telling you something false by omission.
What each scan depth actually does
Light Free plan, and the no-signup instant check
Strictly passive: an HTTPS GET, a TLS handshake, DNS lookups. Nothing that touches a port an ordinary visitor would not touch.
Standard Free and Starter
The full deterministic check set — security headers and cookie flags, TLS and certificate posture, DNS and email spoofing (SPF, DMARC, CAA, DNSSEC), exposed services and ports, technology banners, exposed version-control and build files, CORS policy, unencoded reflection of request input, third-party scripts without integrity pinning, form security including CSRF, and the known-vulnerability template sweep.
Deep Growth and above
Everything in Standard plus bounded exploitation, and only with your per-scan acknowledgement: reflected XSS proved with a browser screenshot, SQL injection confirmed by a boolean differential without reading a row, and out-of-band SSRF confirmed by your server calling a collector we run. Plus authenticated testing behind your login.
Full penetration test Business, and the one-off report
Real attack payloads for the classes automated scanners usually skip — path traversal, OS-command injection, server-side template injection, XXE, XPath, open redirect, CRLF — plus object-level authorization (IDOR/BOLA) and mass-assignment testing against your API's own schema, and a measurement of how much your WAF actually blocked.
What we deliberately do not do
No destruction, ever. No data is deleted, no service is knocked over, nothing persists on your systems, and we never move laterally. Payloads are bounded and the destructive-action rules apply at every scan depth, including the full penetration test.
No business-logic testing. Whether your refund flow can be gamed, or one customer can reach another's data through a legitimate-looking sequence, needs a human tester. Any automated product claiming otherwise is overselling, and we would rather say so than have you discover it.
No invented findings. Every claim in a report maps to a tool result or a reproduction we performed. Where something could not be assessed, the report names it rather than leaving a reassuring silence.
Two OWASP categories are not observable from outside — Insecure Design (A04) and Security Logging and Monitoring Failures (A09). No external scanner can assess them, ours included, and every report says so on its face.