Runtime application self-protection (RASP) is security technology that runs inside an application, usually as an agent loaded into its runtime, and watches how the application handles each request in production. When it sees input being used in a dangerous way, for example text from a web form changing the structure of a database query, it can stop that operation, end the session or raise an alert, depending on how it is configured. Because it judges what the code actually does rather than what the request looks like, it can catch some attacks that perimeter filters miss.
At a glance
- RASP sits inside the running application, not in front of it on the network.
- It watches sensitive operations such as database queries, file access and system commands, and checks whether untrusted input is driving them.
- Depending on configuration, it can block the operation, terminate the request or only report it.
- It is tied to specific languages and runtimes, and adds some performance overhead.
- It complements, but generally does not replace, perimeter services such as a WAF or WAAP.
What problem it solves
Some application flaws can’t be fixed quickly. The code may belong to a vendor, the team that wrote it may have moved on, or a fix may need weeks of testing. Meanwhile, the flaw is exposed to the internet. Perimeter filters help, but they inspect requests from the outside and decide based on patterns. Attacks crafted to look like normal traffic can get through, while unusual but legitimate traffic sometimes gets blocked.
RASP adds a layer that sees what the application is actually doing with each request. Because it watches the point where input reaches a database, a file or a command, it can decide with more context whether something harmful is happening. That can reduce exposure to known flaws while they wait for a fix, and to some unknown ones, including zero-day vulnerabilities, although no product catches every attack. It also gives security teams evidence of which attacks reached vulnerable code, which helps prioritize vulnerability management work.
How it works
Instrumentation. An agent is added to the application’s runtime, such as a Java virtual machine, .NET runtime or a Node.js or Python process. Some products are added as a library instead. The agent hooks into functions that matter for security.
Context. For each request, the agent tracks where untrusted input came from and how it is used. A request containing an injection attempt that never reaches a database query may be logged as harmless; one that does change the query’s meaning is treated as an attack.
Response. Configured actions vary: blocking the operation, returning an error, ending the user’s session, or simply recording the event. Most teams start in monitoring mode to see what would be blocked before turning blocking on.
Reporting. Events flow to the vendor’s console and often to the organization’s SIEM or monitoring tools, with details of the request and the code involved.
The agent approach is similar to interactive application security testing (IAST), and some vendors sell both from the same agent. IAST uses it in testing to report flaws; RASP uses it in production to interrupt attacks.
When it matters for buyers
- When a known flaw can’t be patched quickly. RASP is one way to reduce exposure while a fix is developed, though it isn’t a substitute for the fix.
- When you run important custom or legacy web applications. Especially customer portals and APIs, provided the runtime is supported.
- When buying software or hosted applications. Some vendors cite RASP as part of their protection. Ask what it covers and whether they still fix flaws on agreed timelines; runtime protection is a layer, not a remediation plan.
- When comparing application protection options. Our web application and API protection overview covers the perimeter services RASP is usually compared with.
Questions to ask vendors
- Which languages, runtimes, frameworks and versions do you support, including ours?
- Which attack types do you detect, and which can you block versus only report?
- What overhead should we expect per request, and how was it measured?
- If the agent fails or is overloaded, does the application keep running, stop, or let traffic through unprotected?
- Can we run in monitoring-only mode first, and how are false positives tuned?
- How do events reach our SIEM or security operations team?
- How is it priced: per application, per server or per agent?
How it differs from WAAP
Web application and API protection (WAAP) is a perimeter service, usually cloud-delivered, that sits in front of web applications and APIs. It typically combines a web application firewall (WAF) with bot management, API protection and denial-of-service defense. It inspects traffic before it reaches the application, can protect many applications at once regardless of the language they’re written in, and doesn’t need changes inside the application. RASP sits inside one application and sees how its code handles each request, which gives more context for injection-style attacks but nothing for bots or traffic floods, and it needs agent support for each runtime. They answer different questions, so many organizations that adopt RASP keep a perimeter service too.