Introducing Dhal

Résumé

Les systèmes API modernes ne sont pas protégés par une seule frontière. Une application SaaS en production peut se trouver derrière un CDN, un proxy inverse, une passerelle API, une couche d'authentification, du middleware applicatif, des règles de base de données, de l'observabilité et des processus de réponse aux incidents. Chaque couche voit une partie différente de la réalité. La périphérie voit le volume, l'origine et certains signaux réseau. L'authentification voit l'identité. L'application voit les routes, les corps de requête, les tenants, les clés API, les résultats de réponse, les flux métier et les schémas d'échec.

Dhal a été conçu pour la partie de la sécurité que seule l'application peut observer.

Dhal est un firewall applicatif natif d'application et un middleware de sécurité des requêtes pour Node.js. Il s'exécute dans le chemin de la requête et fournit des contrôles déterministes, conscients des routes, pour Express, Fastify, NestJS, Koa, Hono sur Node.js et les applications raw node:http. Il complète les contrôles CDN, edge, réseau, authentification, autorisation, validation et infrastructure. Il ne remplace ni la protection DDoS volumétrique, ni l'autorisation propre à l'application, ni les pratiques de développement sécurisé.

Ce journal explique pourquoi nous l'avons construit, quelles lacunes il comble, quelles hypothèses d'ingénierie ont guidé sa conception et quelle direction nous envisageons pour la protection des requêtes au plus près de l'application.

Pourquoi nous avons construit Dhal

Chez Rokad, nous travaillons sur des systèmes de production où le problème de sécurité est rarement une vulnérabilité isolée. Le scénario récurrent est plus concret : une équipe dispose d'une infrastructure correcte, utilise un framework reconnu, possède une authentification, déploie derrière un CDN ou un proxy, mais n'a pas de manière claire d'exprimer une politique de sécurité des requêtes à l'intérieur de l'application.

Cette lacune apparaît dans des questions d'ingénierie très ordinaires :

• La route de connexion doit-elle avoir une limite différente d'une route publique ?
• Les échecs d'authentification répétés doivent-ils influencer les requêtes suivantes ?
• Un user-agent suspect doit-il être bloqué partout, seulement sur les routes internes, ou simplement enregistré ?
• Une API JSON doit-elle refuser les content types inattendus avant d'exécuter la logique métier ?
• Une nouvelle politique doit-elle commencer en mode monitor et devenir bloquante seulement après des tests de replay ?
• Les décisions de sécurité doivent-elles produire une télémétrie structurée sans exposer de champs sensibles ?
• Plusieurs instances Node.js doivent-elles partager des compteurs et des signaux de sécurité ?

Ces questions ne concernent pas uniquement les grandes entreprises. Elles apparaissent dans les petits SaaS, les dashboards internes, les APIs publiques, les produits d'IA, les marketplaces, les plateformes développeur et les logiciels construits pour des clients. L'application possède souvent le contexte nécessaire pour décider plus justement, mais la décision reste dispersée entre middleware improvisé, handlers de route, extraits de configuration proxy, helpers de rate limit copiés et correctifs appliqués après incident.

Dhal est né pour réduire cette fragmentation.

Nous ne voulions pas créer un paquet qui ajoute seulement quelques signatures d'attaque. Nous voulions une couche de sécurité des requêtes qui traite la configuration comme un artefact de production : explicite, versionné, observable, reproductible et déployable progressivement. Dhal commence donc en mode monitor, prend en charge les profils de route, expose des diagnostics, s'intègre avec des stores distribués, émet des événements structurés et définit un contrat v1 stable.

La thèse centrale : la périphérie ne voit pas tout

Les contrôles de périphérie sont indispensables. Un CDN, un proxy inverse, un WAF cloud, un firewall réseau, une passerelle de limitation et un fournisseur DDoS peuvent filtrer de grands volumes de trafic avant que l'application ne consomme du CPU. C'est le bon niveau pour de nombreux contrôles à l'échelle réseau.

Mais ces systèmes ne possèdent généralement pas toute la sémantique applicative. Ils peuvent ne pas savoir que /api/login est une route de mot de passe, que /api/invoices/:id appartient à un tenant, qu'une requête a échoué cinq fois à l'authentification, qu'un utilisateur est anonyme ou interne, qu'un corps de requête a déjà été parsé par le framework, ou qu'une route a choisi un mode plus strict que le reste de l'application.

Cette distinction est importante car l'abus d'API est souvent contextuel. L'OWASP API Security Top 10 inclut des risques tels que l'authentification cassée, la consommation de ressources non restreinte, l'accès non restreint à des flux métier sensibles, le SSRF et les mauvaises configurations de sécurité. Le projet OWASP Automated Threats classe aussi des comportements comme le credential stuffing, le scanning, le scraping, le token cracking, le carding, le scalping et le denial of inventory comme des abus automatisés de fonctionnalités valides, et pas seulement comme l'exploitation d'un bug isolé.

La thèse de Dhal est simple : conserver la sécurité edge, mais ajouter une couche native d'application capable d'utiliser le contexte applicatif.

La lacune comblée par Dhal

Dhal n'essaie pas de remplacer tous les produits de sécurité. Il occupe un espace précis entre les contrôles d'infrastructure et le code applicatif.

1. Politique consciente des routes

Une route publique, une connexion, un webhook, un upload de fichier, une API d'administration et un endpoint GraphQL n'ont pas le même risque. Une politique globale devient soit trop faible pour les routes critiques, soit trop bruyante pour le trafic normal.

Dhal introduit des profils de route : modes, limites, règles, réponses, tags, suppressions et contrôles de sécurité positive peuvent être configurés par route. Une application peut rester globalement en monitor pendant que certaines routes d'authentification passent en blocage après revue.

2. Déploiement monitor-first

Les contrôles de sécurité échouent lorsqu'ils sont activés avec trop de confiance et pas assez de preuves. Les faux positifs ne sont pas seulement gênants ; ils peuvent devenir des incidents de disponibilité. C'est pourquoi le modèle de Dhal commence par l'observation.

En mode monitor, Dhal enregistre ce qu'il aurait bloqué tout en laissant passer la requête. Les équipes peuvent examiner les événements wouldBlock, rejouer du trafic légitime et malveillant, ajuster les suppressions, puis activer le blocage route par route. C'est plus proche de la réduction réelle du risque en production : mesurer d'abord, appliquer ensuite.

3. État distribué pour les vrais déploiements

Dans une démonstration mono-processus, les compteurs mémoire peuvent suffire. En production, plusieurs instances Node.js servent souvent la même API. Les limites, signaux de credential stuffing et résultats de réputation deviennent faibles si chaque instance ne voit qu'une partie du flux.

Dhal prend en charge Redis ou Valkey pour les compteurs partagés et les signaux de sécurité. Il refuse aussi de démarrer en enforcement lorsque la configuration déclare une limitation distribuée sans store distribué disponible. Ce refus est volontaire : un outil de sécurité ne doit pas se dégrader silencieusement vers une posture trompeuse.

4. Protection comportementale

Les signatures sont utiles, mais de nombreux abus modernes sont comportementaux. Le credential stuffing ne se voit pas dans un seul payload suspect ; il apparaît à travers des résultats d'authentification répétés. L'activité bot ne se réduit pas toujours à une chaîne user-agent ; elle peut nécessiter un score, plusieurs signaux et des contrôles explicites contre les faux positifs.

Dhal combine SQL injection, XSS, path traversal, SSRF, RCE, SSTI, probes GraphQL, scoring bot, honeypots, credential stuffing, validation de content type, contrôles de headers, limites de payload et politiques par route. L'objectif n'est pas de promettre une détection parfaite. L'objectif est de fournir une surface de décision cohérente qu'une équipe de production peut comprendre.

5. Décisions observables et respectueuses de la vie privée

Une décision de sécurité est incomplète si les opérateurs ne peuvent pas l'expliquer. Mais la télémétrie peut aussi créer un risque de confidentialité si elle capture trop. Dhal inclut donc des événements structurés, OpenTelemetry, des webhooks signés et des contrôles de redaction pour les champs comme l'adresse IP, l'identité et le user-agent.

Le but n'est pas de journaliser des données sensibles. Le but est de produire une trace opérationnelle : quelle décision a été prise, pourquoi, quelle règle a contribué, quelle route a été touchée et comment reproduire ou ajuster le comportement.

6. Automatisation revue par les ingénieurs

Dhal inclut l'onboarding guidé avec dhal add, les diagnostics avec dhal doctor, l'évaluation de préparation avec dhal readiness --production, ainsi que l'inspection et la génération de politique depuis OpenAPI. La contrainte de conception est que la configuration générée doit rester revue par un humain.

Les politiques générées restent en mode monitor. Les profils de route gérés par le propriétaire sont préservés. Dhal ne modifie pas automatiquement le code applicatif sans commande explicite d'écriture. L'automatisation devient utile sans devenir enforcement invisible.

Hypothèses d'ingénierie

Premièrement, la politique de sécurité a besoin de localité. Plus une politique est proche du comportement qu'elle protège, plus elle est facile à tester, revoir et maintenir. La configuration par route appartient près de l'application, car l'application possède la sémantique de ses routes.

Deuxièmement, la sécurité de production est aussi une propriété de disponibilité. Une couche qui casse régulièrement des utilisateurs légitimes sera contournée ou désactivée. Le mode monitor, le replay, les suppressions, les bypass de santé, le comportement d'erreur interne et la télémétrie bornée rendent la sécurité déployable.

Troisièmement, un outil doit déclarer sa frontière. Dhal s'exécute dans le processus Node.js. Il ne peut pas empêcher l'épuisement de bande passante, de handshake TLS, de sockets, de noyau ou le trafic qui n'atteint jamais l'application. Son rôle est l'évaluation des requêtes au niveau applicatif.

Quatrièmement, l'infrastructure de sécurité open source doit être inspectable. Le format de politique, le CLI, les artefacts de release, la matrice de compatibilité et le contrat v1 doivent être visibles. La confiance vient de l'inspection et de la reproductibilité.

Cinquièmement, la configuration de sécurité est du code d'ingénierie. Elle doit être stockée, versionnée, migrée, testée, expliquée et revue. Un fichier dhal.json est un artefact de politique, pas seulement un fichier d'options.

Ce que Dhal inclut aujourd'hui

Dhal v1.1.0 fournit un WAF natif d'application stable pour Node.js avec protection par route, contrôles distribués, sécurité runtime, diagnostics de production et contrat v1.

Sa surface actuelle inclut des adaptateurs pour Express, Fastify, NestJS, Koa, Hono sur Node.js et raw node:http; allowlists, blocklists, CIDR IPv4/IPv6 et réputation optionnelle ; Redis et Valkey pour la limitation distribuée et les signaux partagés ; règles pour injections, traversal, SSRF, RCE, SSTI, GraphQL, automation, bots, honeypots et credential stuffing ; contrôles positifs pour APIs JSON ; modes et limites par route ; OpenTelemetry, événements structurés, webhooks signés et redaction ; onboarding guidé, réparation conservatrice, presets de framework et génération de politique OpenAPI.

La valeur n'est pas une règle isolée. Elle réside dans le cycle de vie : générer prudemment, commencer en monitor, observer, rejouer, ajuster, bloquer étroitement, élargir progressivement et garder le système explicable.

Ce que Dhal ne fait pas

Dhal ne remplace pas l'authentification. Il peut utiliser des valeurs d'identité fiables pour améliorer les limites, signaux, télémétrie et politiques de route, mais il ne décide pas si un utilisateur peut accéder à un objet métier.

Dhal ne remplace pas l'autorisation. Les problèmes d'autorisation objet ou fonction doivent être résolus dans la logique applicative, la politique de domaine ou une couche dédiée.

Dhal ne remplace pas la validation. Les schémas applicatifs, types, contraintes d'entrée et validations de domaine restent nécessaires.

Dhal ne remplace pas la protection DDoS. Comme il s'exécute après l'arrivée du trafic dans le processus Node.js, il ne peut pas absorber les attaques volumétriques avant l'exécution applicative.

Dhal ne remplace pas le développement sécurisé. Il aide à inspecter, scorer, limiter, observer et bloquer des requêtes, mais il ne transforme pas du code dangereux en code sûr.

Le futur que nous imaginons

La direction de Dhal est l'infrastructure de sécurité native d'application pour les systèmes JavaScript et TypeScript modernes, avec quelques engagements stables : comportement déterministe, rollout monitor-first, frontières explicites, télémétrie respectueuse de la confidentialité et politique revue par les ingénieurs.

Couverture plus large

L'écosystème Node.js ne se limite plus à Express et Fastify. Les applications utilisent des meta-frameworks, server functions, handlers de style Fetch, routage par fichiers et déploiements mixtes. Les travaux futurs doivent rendre l'adoption plus simple sur ces surfaces sans perdre la clarté du runtime supporté, de l'objet request observé, du résultat response disponible et de l'état partageable.

Meilleure génération de politique

La génération à partir d'OpenAPI est une étape initiale. La configuration de sécurité devrait être dérivée de la structure réelle de l'application, mais jamais appliquée aveuglément. Le futur inclut une meilleure classification des routes, une sécurité positive fondée sur les schémas, des suppressions suggérées, des overrides gérés par le propriétaire et des annotations de confiance.

Déception et résistance aux abus

La sécurité native d'application peut produire des signaux de faible risque pour identifier l'automatisation. Les honeypots de headers, routes, paramètres et chemins sont un début. Les versions futures pourront étendre des contrôles de déception pour bots, scanners, attaques de credentials, énumération de tokens et abus de flux métier.

Protection des formulaires et des flux métier

Beaucoup d'attaques importantes ne sont pas des injections classiques. Elles ciblent login, signup, reset, checkout, parrainage, vouchers, waitlists et inventaire. Dhal devrait faciliter la protection de ces flux à fort abus tout en laissant la logique métier dans l'application. Cela peut inclure des form shields, des contrôles de token, le séquençage des tentatives, des limites par flux et des groupes de routes modélisant un parcours utilisateur.

Intelligence opérationnelle sans télémétrie cachée

Dhal doit continuer à éviter la télémétrie cachée du package. Les outils de sécurité exigent la confiance. Les équipes ont cependant besoin de meilleurs rapports locaux et contrôlés par le propriétaire : meilleure redaction, scoring de posture, analyse de replay, synthèses de faux positifs et détection de drift de politique.

La bonne direction est une intelligence contrôlée par le propriétaire, pas une extraction silencieuse de données.

Conclusion

Dhal existe parce que les APIs modernes ont besoin d'une couche de sécurité qui comprend plus que des adresses IP et des signatures statiques. L'application possède un contexte que la périphérie n'a généralement pas : routes, identités, corps, résultats, tenants, clés API, hypothèses de déploiement et sémantique des flux métier. Ce contexte doit pouvoir être utilisé sans enfouir la sécurité dans du middleware dispersé et des correctifs d'incident.

Le bon modèle n'est pas sécurité edge ou sécurité native d'application. C'est les deux.

Dhal rend la protection de requêtes au niveau application explicite, observable, testable et sûre à déployer. Ses premières versions stables se concentrent sur Node.js car l'écosystème est vaste, divers et opérationnellement fragmenté. Le futur est plus large : plus de frameworks, une meilleure génération de politique, une protection plus sûre des flux métier, des diagnostics plus forts et une base open source que les équipes de production peuvent inspecter et étendre.

Dhal est donc plus qu'une release de paquet. C'est la position de Rokad sur la manière dont la sécurité des requêtes doit être construite : proche de l'application, honnête sur ses limites, conservatrice dans son déploiement et responsable en production.

Références

• Dépôt Dhal : https://github.com/rokadhq/dhal
• Paquet npm Dhal : https://www.npmjs.com/package/@rokadhq/dhal
• Documentation Dhal : https://rokad.co/en/docs/dhal
• Page produit Dhal : https://rokad.co/en/open-source/dhal
• OWASP API Security Top 10 2023 : https://owasp.org/API-Security/editions/2023/en/0x00-header/
• OWASP Automated Threats to Web Applications : https://owasp.org/www-project-automated-threats-to-web-applications/
• NIST SP 800-53 Rev. 5 : https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final