Le RASP — Runtime Application Self-Protection — est une technologie de sécurité qui s'exécute à l'intérieur d'une application et la protège de l'intérieur. En instrumentant le runtime de l'application, le RASP observe comment l'entrée est réellement utilisée et peut détecter et bloquer les attaques au moment de l'exploitation, avec un contexte qu'une défense périmétrique ne voit jamais.
Comment fonctionne le RASP ?
Le RASP s'attache au runtime de l'application — un agent JVM, un profiler .NET, un hook d'instrumentation Node — et intercepte les opérations pertinentes pour la sécurité : requêtes de base de données, accès aux fichiers, exécution de commandes, désérialisation. Lorsque les données d'une requête atteignent l'une de ces opérations d'une manière qui correspond à une exploitation (un paramètre qui réécrit la structure SQL, un chemin qui s'échappe de son répertoire), le RASP peut la journaliser, alerter ou bloquer l'opération dans le processus.
La propriété déterminante est le contexte. Un filtre périmétrique devine la malveillance à partir de la forme de la requête ; le RASP observe ce que le code en fait réellement, ce qui fait disparaître l'essentiel du compromis entre faux positifs et faux négatifs.
RASP vs WAF vs surveillance client-side
| WAF | RASP | Surveillance de la couche navigateur | |
|---|---|---|---|
| Où il s'exécute | Devant l'application | Dans le runtime du serveur | Dans la session du navigateur du visiteur |
| Voit | Requêtes et réponses | L'exécution réelle du code | Les scripts qui s'exécutent sur la page |
| Angle mort | Comment l'entrée est utilisée | Tout le côté client | Les internes du serveur |
| Arrête | Motifs d'attaque connus | Les exploits qui atteignent le runtime | Skimming, scripts injectés, exfiltration de données |
| Déploiement | Au niveau réseau | Agent par langage/runtime | Balise de script |
Où s'arrête le RASP
La frontière du RASP est le processus serveur. Tout ce qui se passe après le départ de la réponse — le JavaScript que votre page et ses dizaines de fournisseurs tiers exécutent dans le navigateur du visiteur — lui est invisible. Une balise d'analytics compromise qui écrème un formulaire de paiement ne touche jamais le runtime instrumenté ; du point de vue du serveur, rien d'anormal ne s'est produit.
Cette faille côté client a ses propres classes d'attaques — injection JavaScript, XSS basé sur le DOM, Magecart — et, pour les pages de paiement, sa propre réponse réglementaire dans les exigences d'inventaire des scripts et de détection de falsification de PCI DSS 4.0.1 (6.4.3 et 11.6.1).
L'équivalent dans la couche navigateur
L'idée derrière le RASP — surveiller le runtime, pas le périmètre — s'applique tout autant au navigateur, où le « runtime » est chaque script qui s'exécute dans une session réelle. C'est ce que fait la surveillance client-side de cside : elle observe ce que chaque script fait réellement pendant son exécution — accès au DOM, lecture de formulaires, requêtes sortantes — et signale les comportements qui ne devraient pas être là. cside n'est pas un RASP ; c'est la même philosophie de protection appliquée à la moitié de l'application que le RASP ne peut pas voir. La plupart des stacks matures finissent avec un WAF au périmètre, un RASP ou des contrôles équivalents dans le runtime du serveur, et une surveillance au runtime dans le navigateur — une sécurité client-side en couches plutôt qu'une seule boîte.
