Introducing Dhal

Zusammenfassung

Moderne API-Systeme werden nicht durch eine einzelne Grenze geschützt. Eine SaaS-Anwendung in Produktion kann hinter einem CDN, einem Reverse Proxy, einem API-Gateway, einer Authentifizierungsschicht, Application Middleware, Datenbankrichtlinien, Observability-Pipelines und Incident-Response-Prozessen laufen. Jede Schicht sieht nur einen Teil der Wahrheit. Die Edge sieht Volumen, Herkunft und Netzwerksignale. Die Authentifizierung sieht Identität. Die Anwendung sieht Routen, Request-Bodies, Tenants, API-Schlüssel, Response-Ergebnisse, Geschäftsflüsse und Fehlermuster.

Dhal wurde für den Teil der Sicherheit gebaut, den nur die Anwendung sehen kann.

Dhal ist ein app-nativer Web Application Firewall und Request-Security-Middleware für Node.js. Es läuft im Request-Pfad und bietet deterministische, routenbewusste Kontrollen für Express, Fastify, NestJS, Koa, Hono auf Node.js und raw node:http-Anwendungen. Dhal ergänzt CDN-, Edge-, Netzwerk-, Authentifizierungs-, Autorisierungs-, Validierungs- und Infrastrukturkontrollen. Es ersetzt keine volumetrische DDoS-Abwehr, keine anwendungsspezifische Autorisierung und keine sichere Softwareentwicklung.

Dieses Journal beschreibt, warum wir Dhal gebaut haben, welche Lücke es füllt, welche technischen Annahmen das Design geprägt haben und welche Zukunft wir für app-nativen Request-Schutz sehen.

Warum wir Dhal gebaut haben

Rokad arbeitet an Produktionssystemen, in denen Sicherheitsprobleme selten eine einzelne offensichtliche Schwachstelle sind. Das wiederkehrende Muster ist praktischer: Ein Team hat solide Infrastruktur, nutzt ein bekanntes Framework, besitzt Authentifizierung, deployt hinter CDN oder Proxy und hat trotzdem keine klare Möglichkeit, Request-Security-Policy in der Anwendung auszudrücken.

Diese Lücke wird in alltäglichen Engineering-Fragen sichtbar:

• Sollte die Login-Route ein anderes Limit haben als eine öffentliche Route?
• Sollten wiederholte Authentifizierungsfehler spätere Requests beeinflussen?
• Sollte ein verdächtiger User-Agent global blockiert, nur auf internen Routen blockiert oder nur beobachtet werden?
• Sollte eine JSON-API unerwartete Content Types ablehnen, bevor Business-Logik ausgeführt wird?
• Sollte eine neue Policy erst im Monitor-Modus starten und erst nach Replay-Tests blockieren?
• Sollten Security-Entscheidungen strukturierte Telemetrie erzeugen, ohne sensible Daten offenzulegen?
• Sollten mehrere Node.js-Instanzen gemeinsame Zähler und Security-Signale nutzen?

Diese Fragen sind nicht nur Enterprise-Probleme. Sie entstehen in kleinen SaaS-Anwendungen, internen Dashboards, öffentlichen APIs, AI-Produkten, Marktplätzen, Developer-Plattformen und Agenturprojekten. Die Anwendung hat oft genug Kontext für eine bessere Entscheidung, aber die Entscheidung ist über improvisierte Middleware, Route Handler, Proxy-Snippets, kopierte Rate-Limit-Helfer und incidentgetriebene Patches verteilt.

Dhal entstand, um diese Fragmentierung zu reduzieren.

Wir wollten kein Paket bauen, das nur einige Angriffssignaturen hinzufügt. Wir wollten eine Request-Security-Schicht, die Konfiguration als Produktionsartefakt behandelt: explizit, versioniert, beobachtbar, reproduzierbar und schrittweise ausrollbar. Deshalb startet Dhal im Monitor-Modus, unterstützt Routenprofile, stellt Diagnostik bereit, integriert sich mit verteilten Stores, erzeugt strukturierte Events und definiert einen stabilen v1-Vertrag.

Die zentrale These: Die Edge sieht nicht alles

Edge-Kontrollen sind unverzichtbar. CDN, Reverse Proxy, Cloud-WAF, Netzwerk-Firewall, Rate-Limit-Gateway und DDoS-Anbieter können große Mengen unerwünschten Traffics filtern, bevor die Anwendung CPU verbraucht. Für viele netzwerkweite Kontrollen ist das die richtige Ebene.

Aber Edge-Systeme kennen meist nicht die vollständige Anwendungsssemantik. Sie wissen möglicherweise nicht, dass /api/login ein Passwort-Endpunkt ist, dass /api/invoices/:id zu einem Tenant gehört, dass ein Request in der letzten Minute fünfmal an Authentifizierung gescheitert ist, ob ein Benutzer anonym oder intern ist, ob ein Body bereits vom Framework geparst wurde oder ob eine Route bewusst einen strengeren Modus gewählt hat.

Der Unterschied ist wichtig, weil API-Missbrauch oft kontextabhängig ist. OWASP API Security Top 10 nennt unter anderem gebrochene Authentifizierung, uneingeschränkten Ressourcenverbrauch, uneingeschränkten Zugriff auf sensible Geschäftsflüsse, SSRF und Security Misconfiguration. OWASP Automated Threats klassifiziert außerdem Muster wie Credential Stuffing, Scanning, Scraping, Token Cracking, Carding, Scalping und Denial of Inventory als automatisierten Missbrauch gültiger Webfunktionalität, nicht nur als Ausnutzung eines einzelnen Implementierungsfehlers.

Dhals These ist einfach: Edge-Security bleibt bestehen, aber eine app-native Schicht muss Anwendungskontext nutzen können.

Welche Lücke Dhal füllt

Dhal versucht nicht, jedes Sicherheitsprodukt zu ersetzen. Es füllt eine konkrete Lücke zwischen Infrastrukturkontrollen und Anwendungscode.

1. Routenbewusste Policy

Eine öffentliche Route, ein Login, ein Webhook, ein File Upload, eine Admin-API und ein GraphQL-Endpunkt tragen nicht dasselbe Risiko. Eine globale Policy ist entweder zu schwach für kritische Routen oder zu laut für normalen Traffic.

Dhal führt Routenprofile ein: Modi, Limits, Regeln, Responses, Tags, Suppressions und Positive-Security-Kontrollen können pro Route konfiguriert werden. Eine Anwendung kann global im Monitor-Modus laufen, während ausgewählte Authentifizierungsrouten nach Prüfung blockieren.

2. Monitor-first Rollout

Security-Kontrollen scheitern, wenn sie mit zu viel Vertrauen und zu wenig Evidenz aktiviert werden. False Positives sind nicht nur störend; sie können zu Availability-Incidents werden. Deshalb beginnt Dhals Modell mit Beobachtung.

Im Monitor-Modus zeichnet Dhal auf, was es blockiert hätte, lässt den Request aber passieren. Teams können wouldBlock-Events prüfen, legitimen und bösartigen Traffic replayen, Suppressions anpassen und anschließend pro Route blockieren. Das entspricht eher der realen Risikoreduktion in Produktion: erst messen, dann erzwingen.

3. Verteilter Zustand für reale Deployments

In einer Single-Process-Demo reichen Memory-Zähler. In Produktion bedienen oft mehrere Node.js-Instanzen dieselbe API. Rate Limits, Credential-Stuffing-Signale und Reputationsentscheidungen werden schwach, wenn jede Instanz nur einen Ausschnitt sieht.

Dhal unterstützt Redis oder Valkey für gemeinsame Zähler und Security-Signale. Es verweigert außerdem den Start eines Enforcement-Deployments, wenn die Konfiguration Redis-basiertes Rate Limiting deklariert, aber kein verteilter Store bereitgestellt wird. Diese Weigerung ist absichtlich: Ein Security-Tool darf nicht still in eine irreführende Haltung degradieren.

4. Verhaltensbasierter Schutz

Signaturen sind nützlich, aber moderner Missbrauch ist häufig verhaltensbasiert. Credential Stuffing erkennt man nicht an einem einzelnen verdächtigen Payload, sondern an wiederholten Authentifizierungsergebnissen. Bot-Aktivität ist nicht immer nur ein User-Agent-String; sie kann Scoring, mehrere Signale und explizite False-Positive-Kontrollen erfordern.

Dhal kombiniert SQL Injection, XSS, Path Traversal, SSRF, RCE, SSTI, GraphQL-Probes, Bot Scoring, Honeypots, Credential-Stuffing-Erkennung, Content-Type-Prüfung, Header-Kontrollen, Payload-Limits und Routenpolicy. Das Ziel ist nicht perfekte Erkennung zu behaupten. Das Ziel ist eine kohärente Entscheidungsfläche, über die ein Produktionsteam nachdenken kann.

5. Beobachtbare und datenschutzbewusste Entscheidungen

Eine Security-Entscheidung ist unvollständig, wenn Operatoren sie nicht erklären können. Telemetrie kann aber selbst ein Datenschutzrisiko erzeugen, wenn sie zu viel erfasst. Dhal enthält daher strukturierte Events, OpenTelemetry, signierte Webhooks und Redaction-Kontrollen für Felder wie IP-Adresse, Identität und User-Agent.

Das Ziel ist nicht, sensible Request-Daten zu dumpen. Das Ziel ist ein operativer Datensatz: welche Entscheidung getroffen wurde, warum, welche Regel beteiligt war, welche Route betroffen war und wie das Verhalten reproduziert oder angepasst werden kann.

6. Reviewbare Automatisierung

Dhal enthält geführtes Onboarding mit dhal add, Diagnostik mit dhal doctor, Readiness-Bewertung mit dhal readiness --production sowie OpenAPI-Inspektion und Policy-Generierung. Die zentrale Designbedingung: Generierte Security-Konfiguration muss reviewbar bleiben.

Generierte Policies bleiben im Monitor-Modus. Besitzerverwaltete Routenprofile werden erhalten. Dhal patcht Anwendungscode nicht automatisch ohne explizite Schreibbefehle. Automatisierung hilft, aber sie wird nicht zu unsichtbarem Enforcement.

Technische Annahmen hinter dem Design

Erstens braucht Security-Policy Lokalität. Je näher eine Policy am Verhalten liegt, das sie schützt, desto leichter ist sie zu testen, zu reviewen und zu warten. Routenbezogene Konfiguration gehört nahe an die Anwendung, weil die Anwendung die Semantik ihrer Routen besitzt.

Zweitens ist Produktionssicherheit auch eine Availability-Eigenschaft. Eine Schicht, die gültige Nutzer regelmäßig bricht, wird umgangen oder deaktiviert. Monitor-Modus, Replay, Suppressions, Health-Bypasses, internes Fehlerverhalten und begrenzte Telemetrie machen Sicherheit deploybar.

Drittens muss ein Tool seine Grenze erklären. Dhal läuft im Node.js-Prozess. Es kann keine Bandbreitenerschöpfung, TLS-Handshake-Erschöpfung, Socket- oder Kernel-Probleme und keinen Traffic verhindern, der die Anwendung nie erreicht. Seine Rolle ist Request-Auswertung auf Anwendungsebene.

Viertens muss Open-Source-Security-Infrastruktur inspizierbar sein. Policy-Format, CLI-Verhalten, Release-Artefakte, Kompatibilitätsmatrix und v1-Vertrag sollten sichtbar sein. Vertrauen entsteht durch Inspektion und Reproduzierbarkeit.

Fünftens ist Security-Konfiguration Engineering-Code. Sie muss gespeichert, versioniert, migriert, getestet, erklärt und reviewed werden. Eine dhal.json ist ein Policy-Artefakt, nicht nur eine Optionsdatei.

Was Dhal heute umfasst

Dhal v1.1.0 bietet einen stabilen app-nativen WAF für Node.js mit routenbewusstem Schutz, verteilten Kontrollen, Runtime Safety, Produktionsdiagnostik und stabilem v1-Vertrag.

Die aktuelle Oberfläche umfasst Adapter für Express, Fastify, NestJS, Koa, Hono auf Node.js und raw node:http; IP-Allowlists und Blocklists, IPv4/IPv6-CIDR und optionale Reputation; Redis und Valkey für verteiltes Rate Limiting und gemeinsame Signale; Regeln für Injection-Probes, Traversal, SSRF, RCE, SSTI, GraphQL, Automation, Bots, Honeypots und Credential Stuffing; Positive-Security-Kontrollen für JSON-APIs; Routenmodi und Limits; OpenTelemetry, strukturierte Events, signierte Webhooks und Redaction; geführtes Onboarding, konservative Reparatur, Framework-Presets und OpenAPI-Policy-Generierung.

Der Wert liegt nicht in einer einzelnen Regel. Er liegt im Lebenszyklus: vorsichtig generieren, im Monitor starten, beobachten, replayen, anpassen, eng blockieren, schrittweise erweitern und erklärbar bleiben.

Was Dhal bewusst nicht tut

Dhal ersetzt keine Authentifizierung. Es kann vertrauenswürdige Identitätswerte für Limits, Signale, Telemetrie und Routenpolitik nutzen, entscheidet aber nicht, ob ein Nutzer Zugriff auf ein Geschäftsobjekt hat.

Dhal ersetzt keine Autorisierung. Broken Object Level Authorization und Broken Function Level Authorization müssen in Anwendungscode, Domain-Policy oder einer dedizierten Autorisierungsschicht gelöst werden.

Dhal ersetzt keine Validierung. Anwendungsschemas, Typprüfungen, Eingabebeschränkungen und Domain-Validierung bleiben notwendig.

Dhal ersetzt keine DDoS-Abwehr. Weil es nach dem Eintreffen des Traffics im Node.js-Prozess läuft, kann es volumetrische Angriffe nicht vor der Anwendungsausführung absorbieren.

Dhal ersetzt keine sichere Entwicklung. Es hilft beim Inspizieren, Scoring, Limitieren, Beobachten und Blockieren von Requests, macht unsicheren Code aber nicht automatisch sicher.

Die Zukunft, die wir sehen

Dhals langfristige Richtung ist app-native Sicherheitsinfrastruktur für moderne JavaScript- und TypeScript-Systeme. Dabei sollen wenige Verpflichtungen stabil bleiben: deterministisches Verhalten, Monitor-first-Rollout, explizite Grenzen, datenschutzbewusste Telemetrie und reviewbare Policy.

Breitere Framework- und Runtime-Abdeckung

Das Node.js-Ökosystem besteht nicht mehr nur aus Express und Fastify. Produktionsanwendungen nutzen Meta-Frameworks, Server Functions, Fetch-artige Handler, File-based Routing und gemischte Deployment-Ziele. Zukünftige Arbeit soll Adoption auf diesen Oberflächen erleichtern, ohne die Schutzgrenze zu verwischen: wo inspiziert Dhal, welches Request-Objekt erhält es, welches Response-Ergebnis kann es beobachten und welcher Zustand kann geteilt werden?

Bessere Policy-Generierung

OpenAPI-Policy-Generierung ist ein früher Schritt. Security-Konfiguration sollte aus realer Anwendungsstruktur abgeleitet werden, aber nie blind erzwungen werden. Zukünftige Arbeit sollte Routenklassifikation, schema-basierte Positive Security, vorgeschlagene Suppressions, owner-managed Overrides und Confidence-Hinweise verbessern.

Deception und Missbrauchsresistenz

App-native Sicherheit kann risikoarme Signale erzeugen, die Automatisierung erkennbar machen. Honeypot-Header, Routen, Parameter und täuschende Pfade sind erste Beispiele. Künftige Versionen können strukturiertere Deception-Kontrollen für Bots, Scanner, Credential-Angriffe, Token Enumeration und Geschäftsfluss-Automation erweitern.

Schutz für Formulare und Geschäftsflüsse

Viele schädliche Angriffe sind keine klassischen Injections. Sie treffen Login-, Signup-, Reset-, Checkout-, Referral-, Voucher-, Waitlist- und Inventory-Flows. Dhal sollte solche High-Abuse-Flows schützen, ohne Business-Logik aus der Anwendung zu entfernen. Dazu können Form Shields, Token-Kontrollen, Attempt-Sequencing, Flow-Limits und Routengruppen gehören.

Operative Intelligenz ohne versteckte Telemetrie

Dhal sollte weiterhin keine versteckte Package-Telemetrie verwenden. Security-Tools brauchen Vertrauen. Teams benötigen dennoch bessere lokale und owner-kontrollierte Einsichten: bessere Redaction, Posture Scoring, Replay-Analyse, False-Positive-Zusammenfassungen und Policy-Drift-Erkennung.

Die richtige Richtung ist owner-kontrollierte Einsicht, nicht stille Datenextraktion.

Fazit

Dhal existiert, weil moderne APIs eine Sicherheitsschicht brauchen, die mehr versteht als IP-Adressen und statische Signaturen. Die Anwendung besitzt Kontext, den die Edge meist nicht hat: Routen, Identitäten, Bodies, Ergebnisse, Tenants, API-Schlüssel, Deployment-Annahmen und Geschäftsfluss-Semantik. Dieser Kontext sollte nutzbar sein, ohne Security-Logik über verstreute Middleware und incidentgetriebene Patches zu verteilen.

Das richtige Modell ist nicht Edge-Security oder app-native Security. Es ist beides.

Dhal macht Request-Schutz auf Anwendungsebene explizit, beobachtbar, testbar und sicher deploybar. Die ersten stabilen Releases konzentrieren sich auf Node.js, weil das Ökosystem groß, vielfältig und operativ fragmentiert ist. Die Zukunft ist breiter: mehr Frameworks, bessere Policy-Generierung, sichererer Schutz von Geschäftsflüssen, stärkere Diagnostik und eine Open-Source-Grundlage, die Produktionsteams inspizieren und erweitern können.

Dhal ist daher mehr als ein Package-Release. Es ist Rokads Position dazu, wie Request Security gebaut werden sollte: nah an der Anwendung, ehrlich über Grenzen, konservativ im Rollout und verantwortlich in Produktion.

Referenzen

• Dhal Repository: https://github.com/rokadhq/dhal
• Dhal npm Package: https://www.npmjs.com/package/@rokadhq/dhal
• Dhal Dokumentation: https://rokad.co/en/docs/dhal
• Dhal Produktseite: 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