RASP

What Is RASP?

Runtime Application Self-Protection (RASP) is a security technology that runs inside an application and intercepts every request, function call, and data operation at runtime to detect and block active attacks. Unlike perimeter defenses such as web application firewalls (WAFs) that inspect incoming traffic from outside the application, RASP operates within the application’s runtime environment and has full context about the code being executed, the data being processed, and the user session making the request.

RASP was first defined by Gartner in 2012 as an evolution of application security that moves protection closer to the code. The core idea is that an application should be capable of defending itself rather than relying entirely on external security controls. When a RASP agent detects a SQL injection payload being incorporated into a database query, it does not just log a warning — it blocks the query from executing, terminates the malicious request, and alerts the security team, all in real time.

This approach is fundamentally different from traditional security tools. A WAF sees raw HTTP requests and must guess whether a payload is malicious based on pattern matching. A RASP agent sees the actual database query being constructed with the malicious payload and can make a definitive determination. This contextual awareness dramatically reduces false positives and eliminates the evasion techniques that attackers commonly use to bypass WAFs.

How It Works

RASP agents are deployed as part of the application runtime, similar to IAST agents. For Java applications, this means a -javaagent at startup. For Node.js, it involves requiring a protection module before any other code runs. The agent hooks into critical functions — database drivers, file system APIs, command execution functions, serialization libraries — and monitors every invocation.

Here is how RASP protection works for a Node.js application vulnerable to command injection:

// Vulnerable: user input passed directly to shell command
const { exec } = require('child_process');

app.get('/ping', (req, res) => {
  const host = req.query.host;
  exec(`ping -c 4 ${host}`, (error, stdout) => {
    res.send(stdout);
  });
});

// An attacker could send: /ping?host=8.8.8.8;cat /etc/passwd

Without RASP, this endpoint allows arbitrary command execution. With RASP enabled, the agent intercepts the exec() call, analyzes the command string, detects that user input from req.query.host contains shell metacharacters being passed to a system command, and blocks execution before the operating system ever sees the payload.

The secure fix eliminates the vulnerability at the code level:

// Fixed: use execFile with arguments array, avoiding shell interpretation
const { execFile } = require('child_process');
const validator = require('validator');

app.get('/ping', (req, res) => {
  const host = req.query.host;
  if (!validator.isFQDN(host) && !validator.isIP(host)) {
    return res.status(400).send('Invalid host');
  }
  execFile('ping', ['-c', '4', host], (error, stdout) => {
    res.send(stdout);
  });
});

RASP deployment is typically configured at application startup:

# Deploy a Java application with RASP protection enabled
java -javaagent:/opt/rasp/agent.jar \
     -Drasp.mode=block \
     -Drasp.app.name=payment-service \
     -Drasp.server=https://rasp-console.internal \
     -jar payment-service.jar

The mode=block setting instructs the agent to actively prevent attacks. Teams often start with mode=monitor to observe detections without impacting traffic, then switch to blocking mode once they are confident in the agent’s accuracy.

Why It Matters

RASP provides a critical last line of defense for applications in production. Even with thorough SAST, DAST, and code review processes, vulnerabilities reach production. Zero-day vulnerabilities in frameworks and libraries, misconfigurations introduced during deployment, and logic flaws that evade automated tools all create windows of exposure. RASP closes those windows by blocking exploitation attempts in real time, regardless of whether the underlying vulnerability has been patched.

RASP is particularly valuable for protecting legacy applications that cannot be easily updated or rewritten. When a critical vulnerability is disclosed in an old framework version, patching may require weeks of testing and regulatory approval. RASP can block exploitation of that vulnerability within minutes of detection, providing virtual patching while the development team works on a permanent fix.

The operational intelligence that RASP produces is also highly valuable. Every blocked attack provides data about what attackers are targeting, which payloads they are using, and which parts of the application are under active threat. This intelligence feeds back into the development process, helping teams prioritize which vulnerabilities to fix first based on real-world attack activity rather than theoretical severity scores.

Best Practices

• Start in monitoring mode before enabling blocking. Observe RASP detections for a few weeks to understand baseline behavior and verify that legitimate requests are not being misidentified as attacks.
• Deploy RASP alongside, not instead of, application fixes. RASP is a safety net, not a substitute for writing secure code. Use it to protect against unknown vulnerabilities and zero-days while ensuring that known vulnerabilities are fixed in code.
• Monitor performance impact continuously. RASP adds latency to every intercepted function call. Profile your application with the agent enabled and set performance budgets to ensure the security overhead stays within acceptable limits.
• Integrate RASP alerts into your incident response workflow. RASP detections in blocking mode indicate active exploitation attempts. Route these alerts to your security operations team for investigation and response.

Common Mistakes

• Using RASP as an excuse to skip security testing. Teams sometimes rationalize that RASP protection means they do not need SAST, DAST, or penetration testing. This is dangerous — RASP cannot protect against every attack class, and relying on a single control creates a single point of failure.
• Deploying RASP without performance testing. The overhead of runtime interception varies by application and workload. Deploying to production without benchmarking can cause latency spikes, timeout errors, and degraded user experience.
• Ignoring RASP alerts in monitoring mode. Monitoring mode is for tuning and validation. If the team deploys RASP in monitoring mode and never reviews the alerts or transitions to blocking mode, the technology provides zero protection.
• Assuming RASP handles all attack types. RASP excels at detecting injection attacks (SQL, command, LDAP, XPath) but may not catch business logic flaws, authorization bypasses, or rate-limiting issues. A comprehensive security strategy requires multiple layers of defense.