What "invasive" means here
Every standard NANOTESTING scan is non-invasive: it reads, fingerprints, and probes without sending exploit payloads or mutating state. The Invasive Testing add-on ($299/month) unlocks the four active checks that go further - they send real SQL injection / XSS / SSRF payloads, generated API mutations, privileged PATCH requests, and spoofed host headers. These find classes of bug a passive scan structurally cannot, but they must only run where you are authorized to actively test.
The safety model: three gates
No active payload is ever sent unless all three of these are true:
- Your workspace is identity-verified.At least one of personal identity (KYC) or company (KYB) verification must be approved. Active-attack testing is only available to verified customers — this gate applies to both buying the add-on and authorizing a target.
- The workspace has the add-on. Enable it under Billing($299/mo, Growth or Agency plan). This flips
invasive_addon_enabledon your billing profile. - The target is authorized.Open the target's detail page and turn on Authorize invasive testing. We stamp who authorized it and when. This is your written consent that you own the target and may actively attack it.
Turn either gate off and the active checks immediately stop for that scan and report as skipped in the live task list. We strongly recommend pointing invasive testing at a staging environment, not production.
What each check sends
| Check | Surface | What goes out |
|---|---|---|
| Active web scanner (OWASP ZAP) | Web | Spider + active scan: SQL injection, reflected / DOM / stored XSS, CSRF, SSRF, path traversal, command injection, XXE, HTTP parameter pollution, server-side template injection. ~5 min budget. source_tool=zap. |
| OpenAPI contract fuzz (Schemathesis) | API | Property-based fuzzing against a discovered OpenAPI / Swagger spec with generated POST / PUT / DELETE requests. Catches status-code, schema, and content-type conformance breaks plus 500s. Only runs when a machine-readable spec is reachable. |
| Mass-assignment probe | API | PATCHes self-profile endpoints (/api/me, /api/profile, ...) with privileged extra fields (role, isAdmin, permissions, plan, organization_id). A reflected privilege is a confirmed CWE-915 critical. Needs a stored auth secret. |
| Host-header injection probe | Web | Re-requests the homepage with a spoofed Host / X-Forwarded-Host and flags the canary reflected into a redirect Location, a <base href>, or an absolute link - the primitive behind password-reset poisoning and web-cache poisoning (CWE-644). GET only. |
Mobile apps: testing the backend, truthfully
A mobile binary is analyzed statically — nothing is "run." But a mobile app's real attack surface is the backend API it talks to, and those base URLs are almost always hardcoded in the binary. When a mobile target is authorized for invasive testing, the worker:
- extracts the first-party backend hosts from the decompiled tree (filtering out the SDK / analytics / CDN noise every app embeds),
- actively tests only the backend hosts you have verified ownership of (a verified target in your workspace with the same host or parent/child domain), and
- emits an informational finding that lists every backend host it discovered, which one it actively tested, and which it refused to test because ownership was not proven.
This is the key safety rule: a mobile binary routinely embeds third-party / partner API hosts (payment, auth, integrations) that you do not own. We neversend attack payloads at a host you have not verified — those are reported so you can add and verify them as targets first. We also do not run a device emulator or instrument the app at runtime. The data only reflects what was actually tested.
Per-target and per-tool control
Authorization is per target, so you can run invasive testing against your staging API while every production target stays non-invasive. You can also disable an individual tool on a single target from its scan profile (for example, keep the ZAP active scan but skip the mass-assignment PATCHes) without dropping the whole add-on.
Reading the findings
Invasive findings join the same dashboard as every other finding, tagged by source tool. Mass-assignment hits are confirmed critical (the reflected privileged field is direct proof). Host-header redirect reflections are medium; base-href / absolute-link reflections are lowbecause exploitability depends on the flow and on caching. ZAP and Schemathesis findings carry the tool's own confidence, mapped onto our severity scale with the CWE preserved.
What we still never do
- No denial-of-service, brute-force, or resource-exhaustion payloads.
- No testing of a target that is not both owned-and-verified and explicitly authorized.
- No persistence: the probes do not plant data, create accounts, or leave artifacts beyond the single mutation a check needs to confirm a bug.
- No third-party or shared-tenant targets - active payloads go only to the single authorized target.
See the safe-scanning policy for the full authorization contract and data-handling guarantees.