Introducing Dhal

Resumen

Los sistemas API modernos no se protegen desde un único perímetro. Una aplicación SaaS en producción puede operar detrás de un CDN, un proxy inverso, un gateway de APIs, autenticación, middleware de aplicación, políticas de base de datos, observabilidad y procesos de respuesta a incidentes. Cada capa observa una parte distinta del sistema. El borde ve volumen, origen y patrones de red. La capa de autenticación ve identidad. La aplicación ve rutas, cuerpos de petición, tenants, claves API, resultados de respuesta, flujo de negocio y patrones de error.

Dhal fue construido para la parte de la seguridad que solamente la aplicación puede ver.

Dhal es un firewall de aplicación web nativo de aplicación y middleware de seguridad de peticiones para Node.js. Se ejecuta dentro del camino de la petición y proporciona controles deterministas y conscientes de ruta para Express, Fastify, NestJS, Koa, Hono sobre Node.js y aplicaciones raw node:http. Complementa CDN, borde, red, autenticación, autorización, validación e infraestructura. No reemplaza la protección contra DDoS volumétrico, la autorización específica de la aplicación ni las prácticas de desarrollo seguro.

Este journal explica por qué lo construimos, qué vacío llena, qué hipótesis de ingeniería guiaron su diseño y qué futuro imaginamos para una protección de peticiones más cercana a la aplicación.

Por qué construimos Dhal

En Rokad trabajamos con sistemas de producción donde el problema de seguridad casi nunca es una vulnerabilidad aislada y evidente. El patrón más común es más práctico: un equipo tiene infraestructura razonable, usa un framework conocido, cuenta con autenticación, despliega detrás de un CDN o proxy, y aun así no tiene una forma clara de expresar política de seguridad de peticiones dentro de la aplicación.

Ese vacío aparece en preguntas habituales de ingeniería:

• ¿La ruta de login debería tener un límite distinto al de una ruta pública?
• ¿Los fallos repetidos de autenticación deberían cambiar la evaluación de futuras peticiones?
• ¿Un user-agent sospechoso debe bloquearse globalmente, solo en rutas internas, o únicamente registrarse?
• ¿Una API JSON debería rechazar content types inesperados antes de que se ejecute la lógica de negocio?
• ¿Una política nueva debería empezar en modo monitor y pasar a bloqueo después de pruebas de replay?
• ¿Las decisiones de seguridad deberían emitir telemetría estructurada sin exponer datos sensibles?
• ¿Varias instancias de Node.js deberían compartir contadores y señales de seguridad?

Estos problemas no pertenecen solo a grandes empresas. Aparecen en SaaS pequeños, dashboards internos, APIs públicas, productos de IA, marketplaces, plataformas de desarrollo y software construido por agencias. La aplicación suele tener el contexto necesario para decidir mejor, pero la decisión queda fragmentada entre middleware improvisado, manejadores de ruta, reglas de proxy, helpers de rate limit copiados y parches aplicados después de incidentes.

Dhal nació para reducir esa fragmentación.

No queríamos un paquete que solo añadiera algunas firmas de ataque. Queríamos una capa de seguridad de peticiones que tratara la configuración como un artefacto de producción: explícito, versionado, observable, reproducible y seguro de desplegar gradualmente. Por eso Dhal empieza en modo monitor, soporta perfiles de ruta, expone diagnósticos, se integra con stores distribuidos, emite eventos estructurados y define un contrato estable v1.

La tesis central: el borde no lo ve todo

Los controles de borde son esenciales. Un CDN, proxy inverso, WAF cloud, firewall de red, gateway de rate limit y proveedor de DDoS pueden filtrar grandes volúmenes de tráfico antes de que la aplicación consuma CPU. Son el lugar correcto para muchos controles a escala de red.

Pero normalmente no tienen toda la semántica de la aplicación. Pueden no saber si /api/login es un endpoint de contraseña, si /api/invoices/:id pertenece a un tenant, si una petición falló autenticación cinco veces en el último minuto, si un usuario es anónimo o interno, si un cuerpo ya fue parseado por el framework o si una ruta eligió deliberadamente un modo más estricto.

La diferencia importa porque el abuso de APIs suele ser contextual. OWASP API Security Top 10 incluye autenticación rota, consumo de recursos no restringido, acceso no restringido a flujos de negocio sensibles, SSRF y misconfiguración de seguridad. OWASP Automated Threats también clasifica patrones como credential stuffing, scanning, scraping, token cracking, carding, scalping y denial of inventory como abuso automatizado de funcionalidad válida, no solamente como explotación de una vulnerabilidad de implementación.

La tesis de Dhal es simple: mantener la seguridad de borde y añadir una capa nativa de aplicación que pueda utilizar contexto de aplicación.

El vacío que llena Dhal

Dhal no intenta reemplazar todos los productos de seguridad. Cubre un espacio específico entre los controles de infraestructura y el código de aplicación.

1. Política consciente de ruta

Una ruta pública, un login, un webhook, una subida de archivos, una API administrativa y un endpoint GraphQL no tienen el mismo riesgo. Una política global termina siendo demasiado débil para rutas críticas o demasiado ruidosa para tráfico normal.

Dhal introduce perfiles de ruta: modos, límites, reglas, respuestas, etiquetas, supresiones y controles positivos pueden configurarse por ruta. Una aplicación puede estar globalmente en monitor mientras rutas de autenticación seleccionadas pasan a bloqueo después de revisión.

2. Despliegue monitor-first

Los controles de seguridad fallan cuando se activan con demasiada confianza y poca evidencia. Los falsos positivos no son solo molestos; pueden convertirse en incidentes de disponibilidad. Por eso el modelo de Dhal comienza observando.

En modo monitor, Dhal registra lo que habría bloqueado mientras deja pasar la petición. Los equipos pueden revisar eventos wouldBlock, reproducir tráfico bueno y malicioso, ajustar supresiones y luego activar bloqueo por ruta. Es un modelo más cercano a cómo se reduce riesgo en producción: medir primero, hacer cumplir después.

3. Estado distribuido para despliegues reales

En una demo de un solo proceso, los contadores en memoria pueden bastar. En producción, varias instancias de Node.js suelen servir la misma API. Los rate limits, señales de credential stuffing y resultados de reputación pierden fuerza si cada instancia solo ve una parte del flujo.

Dhal soporta Redis o Valkey para contadores compartidos y señales de seguridad. También rechaza arrancar en modo de enforcement cuando la configuración declara rate limiting distribuido pero no se ha proporcionado un store distribuido. Esa negativa es deliberada: una herramienta de seguridad no debe degradar silenciosamente su postura.

4. Protección basada en comportamiento

Las firmas son útiles, pero mucho abuso moderno es conductual. Credential stuffing no se detecta por un único payload sospechoso; aparece mediante resultados repetidos de autenticación. La actividad de bots tampoco siempre se reduce a un user-agent; puede requerir scoring, múltiples señales y controles explícitos contra falsos positivos.

Dhal combina categorías como SQL injection, XSS, path traversal, SSRF, RCE, SSTI, probes GraphQL, bot scoring, honeypots, credential stuffing, validación de content type, headers, tamaño de payload y políticas por ruta. El objetivo no es prometer detección perfecta, sino ofrecer una superficie de decisión coherente que un equipo de producción pueda razonar.

5. Decisiones observables y respetuosas con la privacidad

Una decisión de seguridad está incompleta si los operadores no pueden explicarla. Pero la telemetría también puede crear riesgo si captura demasiado. Por eso Dhal incluye eventos estructurados, OpenTelemetry, webhooks firmados y controles de redacción para campos como IP, identidad y user-agent.

El objetivo no es volcar datos sensibles de petición. El objetivo es producir un registro operacional: qué decisión se tomó, por qué, qué regla contribuyó, qué ruta fue afectada y cómo reproducir o ajustar el comportamiento.

6. Automatización revisable

Dhal incluye onboarding guiado con dhal add, diagnósticos con dhal doctor, evaluación de preparación con dhal readiness --production e inspección/generación de política desde OpenAPI. La restricción de diseño es que la configuración generada debe seguir siendo revisable.

Las políticas generadas permanecen en modo monitor. Los perfiles gestionados por el propietario se preservan. Dhal no modifica automáticamente el código de la aplicación sin comandos explícitos de escritura. La automatización ayuda, pero no se convierte en enforcement invisible.

Hipótesis de investigación detrás del diseño

Primero, la política de seguridad necesita localidad. Cuanto más cerca está la política del comportamiento que protege, más fácil es probarla, revisarla y mantenerla. La configuración por ruta pertenece cerca de la aplicación porque la aplicación posee la semántica de sus rutas.

Segundo, la seguridad en producción también es una propiedad de disponibilidad. Una capa que rompe usuarios válidos será deshabilitada o evitada. Monitor mode, replay, supresiones, bypasses de health check, comportamiento ante errores internos y telemetría acotada son mecanismos para hacer la seguridad desplegable.

Tercero, una herramienta debe declarar su frontera. Dhal corre dentro del proceso Node.js. No puede detener agotamiento de ancho de banda, handshake TLS, sockets, kernel o tráfico que nunca llega a la aplicación. Su rol es la evaluación de peticiones en la capa de aplicación.

Cuarto, la infraestructura de seguridad open source debe ser inspeccionable. El formato de política, CLI, artefactos de release, matriz de compatibilidad y contrato v1 deben ser visibles. La confianza viene de la capacidad de inspeccionar y reproducir.

Quinto, la configuración de seguridad es código de ingeniería. Debe almacenarse, versionarse, migrarse, probarse, explicarse y revisarse. Un dhal.json no es solo un archivo de opciones; es un artefacto de política.

Qué incluye Dhal hoy

Dhal v1.1.0 proporciona un WAF nativo de aplicación estable para Node.js con protección por ruta, controles distribuidos, seguridad en runtime, diagnósticos de producción y contrato v1.

La superficie actual incluye adaptadores para Express, Fastify, NestJS, Koa, Hono sobre Node.js y raw node:http; listas de allow/block por IP, CIDR IPv4/IPv6 y reputación opcional; Redis y Valkey para rate limiting distribuido y señales compartidas; reglas para inyección, traversal, SSRF, RCE, SSTI, GraphQL, automatización, bots, honeypots y credential stuffing; controles positivos para APIs JSON; modos y límites por ruta; OpenTelemetry, eventos estructurados, webhooks firmados y redacción; onboarding guiado, reparación conservadora, presets de framework y generación de política desde OpenAPI.

El valor no está en una regla aislada. Está en el ciclo de vida: generar con cautela, empezar en monitor, observar, reproducir, ajustar, bloquear de forma estrecha, expandir gradualmente y mantener el sistema explicable.

Lo que Dhal no hace deliberadamente

Dhal no reemplaza autenticación. Puede usar valores de identidad confiables para mejorar rate limiting, señales, telemetría y políticas de ruta, pero no decide si un usuario tiene permiso sobre un objeto de negocio.

Dhal no reemplaza autorización. Broken object-level authorization y broken function-level authorization deben resolverse en lógica de aplicación, política de dominio o una capa dedicada de autorización.

Dhal no reemplaza validación. Esquemas de aplicación, tipos, restricciones de entrada y validaciones de dominio siguen siendo necesarias.

Dhal no reemplaza protección DDoS. Se ejecuta después de que el tráfico llega al proceso Node.js, por lo que no puede absorber ataques volumétricos antes de la ejecución de la aplicación.

Dhal no reemplaza desarrollo seguro. Ayuda a inspeccionar, puntuar, limitar, observar y bloquear peticiones, pero no convierte código inseguro en seguro por sí mismo.

El futuro que imaginamos

La dirección de Dhal es convertirse en infraestructura de seguridad nativa de aplicación para sistemas JavaScript y TypeScript modernos, preservando compromisos claros: comportamiento determinista, despliegue monitor-first, fronteras explícitas, telemetría con privacidad y política revisable.

Más runtimes y frameworks

El ecosistema Node.js ya no es solo Express y Fastify. Las aplicaciones modernas usan meta-frameworks, server functions, handlers estilo Fetch, file-based routing y despliegues híbridos. El trabajo futuro debe facilitar la adopción en esas superficies sin confundir el límite de protección: dónde inspecciona Dhal, qué objeto de request recibe, qué resultado de response observa y qué estado puede compartir.

Mejor generación de políticas

La generación desde OpenAPI es un primer paso. La configuración de seguridad debería derivarse de la estructura real de la aplicación, pero nunca aplicarse ciegamente. El futuro incluye mejor clasificación de rutas, seguridad positiva basada en esquemas, supresiones sugeridas, overrides gestionados por el propietario y anotaciones de confianza.

Decepción y resistencia al abuso

La seguridad nativa de aplicación puede generar señales de bajo riesgo que identifiquen automatización. Honeypots de headers, rutas, parámetros y paths engañosos son un inicio. Futuras versiones pueden expandir controles de decepción para bots, scanners, ataques de credenciales, enumeración de tokens y abuso de flujos de negocio.

Protección de formularios y flujos de negocio

Muchos ataques dañinos no son inyecciones clásicas. Atacan formularios, login, signup, reset, checkout, referidos, vouchers, waitlists e inventario. Dhal debería facilitar la protección de flujos de alto abuso manteniendo la lógica de negocio en la aplicación. Eso puede incluir form shields, controles de token, secuenciación de intentos, límites por flujo y grupos de rutas que modelen un recorrido de usuario.

Inteligencia operacional sin telemetría oculta

Dhal debe seguir evitando telemetría oculta del paquete. Las herramientas de seguridad requieren confianza. Aun así, los equipos necesitan mejores informes locales y controlados por el propietario: redacción más segura, scoring de postura, análisis de replay, resúmenes de falsos positivos y detección de drift de política.

La dirección correcta es insight controlado por el propietario, no extracción silenciosa de datos.

Conclusión

Dhal existe porque las APIs modernas necesitan una capa de seguridad que entienda más que direcciones IP y firmas estáticas. La aplicación tiene contexto que el borde normalmente no tiene: rutas, identidades, cuerpos, resultados, tenants, claves API, supuestos de despliegue y semántica de flujo de negocio. Ese contexto debe poder usarse sin enterrar lógica de seguridad en middleware disperso y parches posteriores a incidentes.

El modelo correcto no es seguridad de borde o seguridad nativa de aplicación. Es ambas.

Dhal busca hacer la protección de peticiones en la capa de aplicación explícita, observable, testeable y segura de desplegar. Sus primeras versiones estables se centran en Node.js porque el ecosistema es grande, diverso y operacionalmente fragmentado. El futuro es más amplio: más frameworks, mejor generación de política, protección más segura de flujos de negocio, diagnósticos más fuertes y una base open-source que los equipos de producción puedan inspeccionar y extender.

Dhal es, por tanto, más que una release de paquete. Es la posición de Rokad sobre cómo debería construirse la seguridad de peticiones: cerca de la aplicación, honesta sobre sus límites, conservadora en el rollout y responsable en producción.

Referencias

• Repositorio Dhal: https://github.com/rokadhq/dhal
• Paquete npm Dhal: https://www.npmjs.com/package/@rokadhq/dhal
• Documentación Dhal: https://rokad.co/en/docs/dhal
• Página de producto 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