What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
- Exact supported runtime and framework versions: confirm with vendor docs
- Whether the sensor is licensed separately from the base scanner: verify
- Node.js support status: unconfirmed
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
AcuSensor is not a standalone scanner. It is an agent you deploy into the application you are already scanning with Acunetix, and it works by hooking the runtime from the inside while the dynamic scanner attacks from the outside. For Java it is installed as a bridge into the servlet container; for PHP it is a file prepended to execution; for .NET it is injected into the compiled assemblies. Once in place it watches security relevant sinks: database query execution, file system calls, process invocation, deserialization.
When the scanner sends a payload, the sensor reports back what actually happened on the server side. Instead of inferring SQL injection from a response difference, you get the executed query, the source file, the line number and the stack trace that led there. The same channel surfaces things a black box crawler cannot see at all: unhandled exceptions with internal detail, runtime configuration weaknesses, and source files present on disk but not linked from any reachable page.
Where it fits
This belongs in a pre-production environment where you control deployment, typically staging or a dedicated test instance, since it requires modifying the running application. The security team usually owns the scanner while a platform or application team installs the sensor. It only pays off if you are already committed to Acunetix, if the application runs on a supported stack, and if you have a build or deploy process that can carry the agent into the test environment without hand editing servers.
Strengths
- Converts URL and parameter findings into file and line references a developer can act on without reproducing the attack.
- Sharply reduces false positives on injection classes, because the sensor confirms the sink was reached rather than guessing from the response.
- Discovers unlinked and orphaned files that crawling alone will never reach.
- Deployment is additive: you keep the existing dynamic scan workflow and gain context on top of it.
Limitations
- Useless outside the Acunetix ecosystem. It is a scanner accessory, not a product you can adopt on its own.
- Language support is narrow compared with agent based IAST tools that cover Node.js, Python, Ruby and Go.
- Requires write access to the application runtime, which many teams will not permit in shared or production-like environments, and adds a deployment step that drifts out of date.
Who it suits
A good addition for an organization already standardized on Acunetix running Java, PHP or .NET applications, where triage load from dynamic findings is the main pain and you control the test environment. Wrong choice if you want continuous IAST coverage during ordinary functional testing, or if your stack sits outside the supported runtimes.
Used Acunetix AcuSensor? Recommend it under your own name and title.
Recommend this tool