What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current supported runtimes beyond Java and .NET: confirm with vendor
- Packaging and its relationship to the wider Imperva application security portfolio: confirm
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
Imperva's RASP came out of the Prevoty acquisition and keeps that product's distinguishing idea: rather than matching request text against attack signatures, it parses the payload using the grammar of whatever is about to consume it. At the moment the application is going to execute a SQL statement, the agent parses that statement and determines whether untrusted input changed the query's structure rather than only its values. At the moment output is being rendered, it tokenizes the markup and decides whether user-supplied content has introduced executable script. The same approach extends to command execution, path handling and deserialization. This is language-theoretic detection, and the practical consequence is that obfuscation which defeats pattern matching does not help an attacker, because the parser sees the same structure the interpreter will see.
The agent loads into the application process, as a JVM agent or a .NET profiler hook, and instruments the sinks where these decisions are made. Because it judges what the application is about to do, it needs no learning period, traffic baseline or per-application tuning, and it works the same whether traffic arrived encrypted, through a gateway or from an internal queue.
Where it fits
This runs in production, deployed by application or platform teams and owned by security. It complements a perimeter WAF rather than replacing it: the WAF absorbs volumetric and reconnaissance noise, the agent catches what gets through and what never crosses the perimeter at all. The prerequisite is being able to change application startup and accept an in-process component, which in change-controlled environments is the harder part of adoption.
Strengths
- Grammar-based analysis removes signature maintenance and the endless tuning cycle that comes with it.
- Visibility into decrypted, post-routing data means internal traffic and API calls get the same treatment as public web requests.
- Deployment is uniform across applications, since there is no per-application rule set to build.
- Serves as a compensating control when a vulnerable component cannot be upgraded on the required timeline.
Limitations
- Runtime coverage is narrow. If your estate is largely Node, Python, Go or Ruby, this does not cover it.
- An in-process agent adds latency and a failure mode inside the application, and it needs revalidation whenever runtimes or frameworks change.
- Protection covers only the sinks the agent instruments. Logic flaws and authorization errors stay invisible.
Who it suits
Sensible for enterprises with a substantial Java or .NET estate, where legacy applications cannot be remediated at the pace vulnerabilities appear and an existing Imperva footprint makes consolidation attractive. Wrong for polyglot or serverless environments, or for teams unwilling to run vendor code inside their application process.
Used Imperva RASP? Recommend it under your own name and title.
Recommend this tool