RASP — Runtime Application Self-Protection — é uma tecnologia de segurança que roda dentro de uma aplicação e a protege a partir de dentro. Ao instrumentar o runtime da aplicação, o RASP observa como a entrada é de fato usada e pode detectar e bloquear ataques no momento da exploração, com um contexto que uma defesa de perímetro nunca vê.
Como o RASP funciona?
O RASP se acopla ao runtime da aplicação — um agente JVM, um profiler .NET, um hook de instrumentação do Node — e intercepta operações relevantes para a segurança: queries de banco de dados, acesso a arquivos, execução de comandos, desserialização. Quando os dados de uma requisição chegam a uma dessas operações de um jeito que corresponde a uma exploração (um parâmetro que reescreve a estrutura do SQL, um caminho que escapa do seu diretório), o RASP pode registrar, alertar ou bloquear a operação dentro do processo.
A propriedade definidora é o contexto. Um filtro de perímetro adivinha a malícia pela forma da requisição; o RASP observa o que o código realmente faz com ela, o que elimina a maior parte do dilema entre falsos positivos e falsos negativos.
RASP vs WAF vs monitoramento client-side
| WAF | RASP | Monitoramento na camada do navegador | |
|---|---|---|---|
| Onde roda | Na frente do app | Dentro do runtime do servidor | Na sessão do navegador do visitante |
| Vê | Requisições e respostas | A execução real do código | Scripts em execução na página |
| Ponto cego | Como a entrada é usada | Tudo no lado do cliente | Os internos do servidor |
| Impede | Padrões de ataque conhecidos | Exploits que chegam ao runtime | Skimming, scripts injetados, exfiltração de dados |
| Implantação | Em nível de rede | Agente por linguagem/runtime | Tag de script |
Onde o RASP termina
O limite do RASP é o processo do servidor. Tudo o que acontece depois que a resposta sai — o JavaScript que a sua página e as dezenas de fornecedores terceiros dela executam no navegador do visitante — é invisível para ele. Uma tag de analytics comprometida fazendo skimming em um formulário de checkout nunca toca o runtime instrumentado; do ponto de vista do servidor, nada de anormal aconteceu.
Essa lacuna no lado do cliente tem suas próprias classes de ataque — injeção de JavaScript, XSS baseado em DOM, Magecart — e, para páginas de pagamento, sua própria resposta regulatória nos requisitos de inventário de scripts e detecção de adulteração do PCI DSS 4.0.1 (6.4.3 e 11.6.1).
O equivalente na camada do navegador
A ideia por trás do RASP — observar o runtime, não o perímetro — se aplica igualmente ao navegador, onde o "runtime" é cada script executado em uma sessão real. É isso que o monitoramento client-side da cside faz: ele observa o que cada script realmente faz enquanto roda — acesso ao DOM, leitura de formulários, requisições de saída — e sinaliza comportamentos que não deveriam estar ali. A cside não é um RASP; é a mesma filosofia de proteção aplicada à metade da aplicação que o RASP não consegue ver. A maioria dos stacks maduros acaba com um WAF no perímetro, RASP ou controles equivalentes no runtime do servidor e monitoramento em runtime no navegador — uma segurança client-side em camadas em vez de uma única caixa.
