Most of what an automated scanner should do is non-invasive: read the response, fingerprint the stack, check headers and TLS, look for exposed paths — all without sending a single exploit payload. That is the right default. It is safe to run on production, it is fast, and it catches the majority of the obvious gaps.
But a whole class of vulnerabilities simply does not show up unless you send a real payload. You cannot confirm a SQL injection by reading a homepage. You cannot prove a mass-assignment bug without actually PATCHing the field. That is where active DAST — dynamic application security testing — comes in, and it is exactly what the NANOTESTING Invasive Testing add-on unlocks.
The four active checks
- OWASP ZAP active scan. Spider plus active scan against a web target: SQL injection, reflected / DOM / stored XSS, CSRF, SSRF, path traversal, OS command injection, server-side template injection (SSTI), and XXE. When a target has a stored auth secret, the scan runs authenticated so it sees the post-login surface.
- OpenAPI contract fuzzing (Schemathesis). Property-based fuzzing of a discovered OpenAPI / Swagger spec with generated POST / PUT / DELETE requests. It catches status-code, schema, and content-type conformance breaks plus unhandled 500s.
- Mass-assignment probe. PATCHes self-profile endpoints with privileged extra fields (
role,isAdmin,plan,organization_id). If the response reflects one back, that is a confirmed CWE-915 critical — direct evidence the field was accepted. - Host-header injection probe. Re-requests the target with a spoofed
Host/X-Forwarded-Hostand flags the value reflected into a redirect, a<base href>, or an absolute link — the primitive behind password-reset poisoning and web-cache poisoning (CWE-644).
Why it is gated, and how
Active payloads are powerful, which is exactly why they need guardrails. NANOTESTING enforces a three-gate model: nothing fires unless your workspace is identity-verified (an approved KYC or KYB), the add-on is active, and the specific target is explicitly authorized for invasive testing — stamped with who authorized it and when. You can disable any single tool per target, and we recommend pointing invasive testing at a staging environment. We never run denial-of-service, brute-force, or resource-exhaustion payloads.
When to turn it on
Turn on invasive testing when you own a target, you are authorized to actively attack it, and you want evidence that goes beyond "this looks misconfigured" to "we sent the payload and here is what came back." It is the closest an automated tool gets to the first hour of a manual pentest — and it frees your human reviewers to spend their time on the business-logic bugs only humans find.
Read the full setup and safety model in the invasive testing guide.