Implementations may use instrumentation, agents, libraries, runtime hooks, or framework integration. The label does not define one architecture, detection method, enforcement scope, or assurance level.
Because a RASP control can observe application execution, it may connect a request with code paths, queries, data handling, identities, or exceptions that an external control cannot see. Products and implementations differ between monitoring, blocking, and application-specific response.
Key points
Placement and scopeDocument supported runtimes, applications, code paths, inputs, attack classes, operating modes, and any behavior that the control cannot inspect or safely interrupt.
Safe operationTest detection and blocking against representative traffic, measure latency and resource use, protect policy and management access, stage enforcement, and define fail-open, fail-closed, rollback, and evidence-handling behavior.
ValidationConfirm claimed detections with reproducible tests, monitor false positives and false negatives, reassess after application or runtime changes, and ensure alerts reach an accountable response process.
Important limitationRASP does not repair vulnerable code or make the application secure. It can be bypassed, misconfigured, or impaired by unsupported paths, and runtime instrumentation can affect performance or stability.