Signal Sciences Rasp
You set up signal sciences rasp by installing a language module and local agent inside your app server. This pair inspects incoming web requests in real time and blocks attacks before code runs. Most engineering teams add these modules to their build pipelines to protect public web traffic. Still, teams often pair strong web protection with broad internal database roles for their engineers. When an engineer logs in with full admin permissions, web filters do not inspect their direct queries. H
Sciences Rasp: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up signal sciences rasp by installing a language module and local agent inside your app server. This pair inspects incoming web requests in real time and blocks attacks before code runs. Most engineering teams add these modules to their build pipelines to protect public web traffic. Still, teams often pair strong web protection with broad internal database roles for their engineers. When an engineer logs in with full admin permissions, web filters do not inspect their direct queries.
How signal sciences rasp works in your app stack
A runtime protection tool sits right inside the runtime of your web app. You install a small module that matches the programming language of your service. You also run a background agent on the same host or container pod. When a user sends a web request, the language module catches the call first. The module passes request details to the local agent over a local socket. The agent checks the request against attack rules and custom team signals.
If the request looks safe, the agent tells the module to let the code run. If the request holds an injection attack, the agent tells the module to block it. The local agent also talks to a central cloud engine on a regular timer. It sends summary metrics up to the cloud and pulls down updated detection rules. If the cloud link drops, the local agent keeps running with its last rule set. This design keeps latency low because web requests do not wait on external network calls.
Deploying the module and agent across services
Teams start by adding the language package or server module to their app build. Next, they add the agent process to their virtual machine image or container spec. Each agent needs workspace keys so it can pair with the central control plane. Teams store these keys in their secret store and load them when the service boots. Once the agent starts, it shows up in the central dashboard within a few minutes.
In the dashboard, operators start the new service in a log-only mode. This mode tags bad traffic and records alerts without dropping any real user requests. Teams watch these logs for a few days to check for false alarms. They add custom rules to skip safe internal paths or specific partner traffic. Once the logs look clean, the team switches the service to active blocking mode. They also set up alerts to notify the security team when attack spikes happen.
Sciences Rasp: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What runtime web protection solves and what it misses
Runtime web protection is great at stopping external attacks that come through HTTP routes. It catches SQL injection, cross-site scripting, and bad bot traffic at the app layer. Because it lives inside the app, it sees decoded traffic after TLS ends. It also knows which route and handler will process the incoming user payload. This gives security teams clear context without forcing them to write complex network rules.
Still, an app module only sees traffic that flows through the web server itself. It does not watch direct engineer sessions to databases, cloud consoles, or internal servers. When developers debug an issue, they bypass the web app and query the database. Standard identity tools check who logs in, not what individual statements or commands do in flight. A developer with a valid role can still run a broad query that returns sensitive data. Without query inspection and data masking rewriting matched fields like emails, card numbers, or phone numbers, internal sessions remain exposed.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between a network WAF and RASP?
A network WAF filters traffic at the edge before it reaches your server. RASP runs inside the app runtime and inspects requests with full app context.
What happens if the local agent stops working?
The language module is built to fail open if the local agent stops responding. Your web app keeps serving user traffic so an agent crash does not cause downtime.
Does runtime app protection secure direct database queries from engineers?
No, it only inspects traffic that passes through the web app runtime itself. Direct database sessions from engineers or scripts bypass the web module completely.