Jede Web-Anwendung ist eine Angriffsfläche, und die unbequeme Wahrheit ist, dass du nicht sichern kannst, was du nicht gegen echte Angriffe getestet hast. Statische Analyse liest deinen Source und kennzeichnet verdächtige Muster, kann dir aber nicht sagen, ob die bereitgestellte Anwendung tatsächlich Daten leckt, eine injizierte Nutzlast akzeptiert oder ein unauthentifiziertes Admin-Panel freilegt. Das erfordert, die laufende Anwendung so zu pieksen, wie es ein Attacker würde — Dynamische Anwendungssicherheitstests oder DAST. Die gute Nachricht für 2026 ist, dass das quelloffene DAST-Ökosystem reif, fähig und kostenlos ist, das alles von schnellen bekannten-CVE-Checks bis zu vollständigen Crawling-Angriffsscans abdeckt. Der Haken ist, dass kein einzelnes Tool alles gut macht, und die Verwendung einer dort, wo du mehrere brauchst, hinterlässt Lücken.
Dieser Leitfaden erklärt, wie DAST funktioniert, warum die quelloffenen Tools sich gegenseitig ergänzen statt zu konkurrieren, und wie man sie in eine geschichtete Scan-Pipeline montiert, die in CI/CD passt. Die Hauptfiguren sind ZAP, das Vollkern-Proxy-and-Scanner; Nuclei, der schnelle Template-basierte Anfälligkeits-Scanner; Wapiti, der Command-Line-Fuzzing-Scanner; und Nikto, der Veteranen-Server-Konfigurations-Checker. Zu verstehen, wofür jeder ist, ist wie man Abdeckung statt Redundanz aufbaut.
Was DAST tatsächlich macht
Dynamische Testbehandlung der Anwendung als Black Box. Statt Code zu lesen, interagiert ein DAST-Tool mit der laufenden App über HTTP — crawlt ihre Seiten, reicht Formulare ein, ruft ihre APIs auf — und beobachtet, wie sie auf normale und böswillige Eingaben antwortet. Wenn das Senden von ' OR 1=1-- in einem Parameter die Antwort auf eine Art ändert, die SQL-Injection vermuten lässt, ist das ein Signal. Wenn ein reflektiertes Script-Tag unescaped in der Seite zurückkommt, ist das Cross-Site-Scripting. DAST erfasst die Anfälligkeiten, die nur bei Laufzeit existieren: Injection-Flaws, Authentifizierungs- und Session-Probleme, Fehlkonfigurationen, freiliegende Endpoints und Probleme, die entstehen, wie Komponenten tatsächlich interagieren, wenn sie bereitgestellt werden.
DASTs große Stärke ist, dass sie die Realität testen — das tatsächlich laufende System, mit seiner Server, seiner Konfiguration und seinem Laufzeit-Verhalten, nicht ein abstraktes Modell des Source. Die entsprechende Schwäche ist, dass sie nur testen, was sie erreichen können: Wenn der Crawler eine Seite nie findet, oder nicht authentifizieren kann, oder das Client-seitige Routing einer Single-Page-App nicht versteht, wird diese Oberfläche nicht getestet. Das ist, warum Crawling-Qualität und Authentifizierungs-Unterstützung so viel Gewicht haben, und warum sich die Tools sinnvoll unterscheiden, wie gut sie die wahre Oberfläche einer Anwendung entdecken. Es ist auch, warum DAST statische Analyse und Abhängigkeits-Scanning ergänzt statt ersetzt — jede sieht, was die anderen blind sind.
ZAP: das Vollkern-Arbeitstier
ZAP (Zed Attack Proxy), gepflegt von Checkmarx nach seinem langen Run als OWASP-Flaggschiff, ist das vollständigste quelloffene DAST-Tool, und für viele Teams ist es der ganze Stack selbst. Seine Grundlage ist ein abfangendes Proxy: Du routest einen Browser (oder einen automatisierten Crawler) durch ZAP, und es zeichnet jeden Request und Response auf, baut eine Karte der Anwendung. Von diesem Traffic läuft es passive Scans (Probleme aus beobachteten Responses kennzeichnen, ohne anzugreifen) und, auf Anforderung, aktive Scans (Angriffsnutzlasten senden, um Anfälligkeiten zu bestätigen). Herum um diesen Kern fügt es einen Spider und einen Ajax-Spider für JavaScript-schwere Apps hinzu, einen Fuzzer, WebSocket-Unterstützung und API-Scanning für REST, GraphQL und SOAP.
ZAPs entscheidender Vorteil für 2026 ist Automatisierung. Seine gepackten Scan-Skripte — ein Baseline (passive) Scan, ein Full (aktiver) Scan und ein API-Scan, getrieben von einer OpenAPI-Spec — werden headless in einem Container ausgeführt, was ZAP zu einer natürlichen Passung für CI/CD macht. Zeige dem Baseline-Scan auf eine Staging-Bereitstellung bei jedem Pull-Request und du bekommst kontinuierliche, Low-Noise-DAST mit fast keinem Setup. Sein Automation Framework und vollständiges HTTP-API ermöglichen es dir, willkürlich komplexe Scans zu skriptieren, und sein Kontext- und Authentifizierungs-Handling lassen es als ein angemeldeter Benutzer testen, das ist, wo die interessanten Anfälligkeiten normalerweise leben. Wenn Leute nach "einem quelloffenen DAST-Tool" fragen, ist ZAP die Antwort, und der ZAP-Spickzettel deckt seine Scan-Modi und API.
Der Tradeoff ist, dass ZAPs Breite mit Gewicht kommt: es ist ein substanzielles Tool mit einer Lernkurve, und ein vollständiger aktiver Scan einer großen Anwendung nimmt Zeit. Das ist ein angemessener Preis für seine Abdeckung, aber das ist, warum die leichteren, schnelleren Tools immer noch daneben einen Platz haben.
Nuclei: schnelle, Template-getriebene Erkennung
Nuclei, von ProjectDiscovery, greift auf einen anderen Teil des Problems an: Geschwindigkeit und Bekannte-Anfälligkeits-Abdeckung. Statt zu crawlen und zu fuzzen, führt Nuclei ein Ziel gegen eine riesige Bibliothek von Community-gepflegten YAML-Templates aus, jede, die beschreibt, wie eine spezifische Thema erkannt wird — ein bekanntes CVE, ein Standard-Credential, eine freiliegende Konfigurationsdatei, eine Fehlkonfiguration. Da die Templates deklarativ sind und Nuclei's Engine schnell und parallel ist, kann es Tausende bekannte Probleme über viele Hosts in Minuten, deterministisch, überprüfen.
Das macht Nuclei zum idealen ersten Pass und dem idealen kontinuierlichen Check. Es glänzt beim Beantworten "ist dieses Ziel anfällig für etwas bereits bekanntes?" — das freiliegende .git-Verzeichnis, das ungepatchte CVE, das verlassene Admin-Panel, die Standard-Login. Die 12.000-plus Community-Templates bedeuten, dass das kollektive Wissen der Sicherheits-Community kodiert und wiederverwendbar ist, und neue Templates erscheinen, wenn neue Anfälligkeiten offengelegt werden. In einer Pipeline ist Nuclei billig genug, um auf jedem Deploy auszuführen und sogar gegen Production (mit Vorsicht), und fängt Rückgänge und neu-offenbarte Probleme schnell. Der Nuclei-Spickzettel deckt Template-Auswahl und Scanning.
Was Nuclei nicht tut, ist neuartige Anfälligkeiten in deine spezifische Anwendungslogik entdecken. Es prüft gegen einen Katalog bekannter Muster; es crawlt nicht deine App und fuzzt nicht ihre eindeutigen Parameter wie ZAP oder Wapiti. Das ist keine Fehler — es ist das Design — aber es ist genau, warum Nuclei mit einem Crawling-Scanner gekoppelt wird statt einen zu ersetzen.
Wapiti und Nikto: fokussierte Spezialisten
Zwei leichtere Tools runden den quelloffenen Stack. Wapiti ist ein Command-Line-Black-Box-Scanner, der als Fuzzer funktioniert: Er crawlt die Anwendung, um URLs und Formulare aufzuzählen, dann injiziert dann Nutzlasten in jeden Parameter und inspiziert die Responses auf Zeichen der Anfälligkeit — SQL-Injection, XSS, Datei-Offenbarung, Kommando-Injection, SSRF und mehr. Es ist leichter und skriptierbar als ZAP, GPL-lizenziert und pip-installierbar, was es einfach macht, in einen CI-Job zu werfen, wenn du aktives Fuzzing ohne ZAPs ganzen Fußabdruck willst. Seine 2026-Releases haben mit neueren Angriffs-Klassen Schritt gehalten, und der Wapiti-Spickzettel deckt sein Modul-System.
Nikto ist der Veteran der Gruppe und besetzt eine schmale aber nützliche Nische: Server-Level-Checks. Es scannt einen Web-Server auf gefährliche Dateien und CGIs, veraltete Server-Software und häufige Fehlkonfigurationen — Tausende Checks gegen den Server selbst statt der Anwendungs-Geschäftslogik. Es ist schnell, einfach und sich ergänzend: Nikto sagt dir, der Server ist fehlkonfiguriert oder läuft etwas Gefährliches, während ZAP und Wapiti die Anwendung testen, die darauf läuft. Für einen schnellen Server-Hygiene-Pass bleibt es der Mühe wert zu laufen.
Montiere eine geschichtete Pipeline
Die Tools ergänzen sich, da sie unterschiedliche Achsen abdecken — Bekannte-Anfälligkeits-Breite, Anwendungslogik-Tiefe und Server-Konfiguration — und die stärkste Haltung schichtet sie nach Kosten und Abdeckung. Eine praktische 2026-Pipeline sieht so aus. Bei jedem Deploy zu Staging, laufe Nuclei für einen schnellen, breiten Sweep bekannter CVEs und Expositionen, und einen ZAP Baseline (passiv) Scan für Low-Noise-Anwendungs-Erkenntnisse — beide sind schnell genug, um ein Pull-Request zu gating. Auf einem Zeitplan (nächtlich oder pro-Release), laufe die schwereren aktiven Scans: einen ZAP Full-Scan und/oder Wapiti um die Parameter und Formulare der Anwendung zu fuzzen und nach neuartigen Injection und Logik-Flaws zu suchen, plus einen Nikto-Pass für Server-Hygiene. Füttere alles in das gleiche Reporting, damit Erkenntnisse gemeinsam triage werden.
Diese Schichtung respektiert die Realität, dass aktive Scans langsam sind und Bekannte-CVE-Checking schnell ist, sodass du den billigen breiten Check konstant durchführst und den teuren tiefen Check periodisch. Sie respektiert auch, dass jedes Tool Blind Spots hat, die die anderen abdecken: Nuclei verpasst neuartige App-Logik-Bugs, die ZAP/Wapiti-Fuzzing erfasst; ZAP/Wapiti verpassen neu-offenbarte CVEs, die Nucleis frische Templates erfasst; beide verpassen Server-Fehlkonfigurationen, die Nikto kennzeichnet. Laufe einen und du hast einen falschen Sicherheits-Sinn; laufe den geschichteten Satz und du hast echte Abdeckung. Der häufigste Fehler, den Teams machen, ist die Annahme eines einzelnen Scanners und die Annahme, dass er umfassend ist — kein DAST-Tool ist, und die quelloffenen sind ausdrücklich entwickelt, um sich zu ergänzen.
Authentifizierung und Umfang: Wo Scans erfolgreich oder scheitern
Ein Punkt, der bestimmt, ob irgendetwas davon funktioniert: DAST testet nur, was es erreichen kann, also sind Authentifizierung und Umfang-Konfiguration das, wo Scans ruhig erfolgreich oder scheitern. Die schwerwiegendsten Anfälligkeiten leben normalerweise hinter einer Login — in der authentifizierten Anwendung, den Admin-Funktionen, den Benutzer-spezifischen Daten. Ein Scanner, der nur die Öffentlichkeit, nicht authentifizierten Seiten testet, testet den am wenigsten interessanten Teil der Angriffsfläche. Jedes ernstes DAST-Tool unterstützt authentifiziertes Scanning (ZAPs Kontexte und Session-Management sind besonders fähig), aber es braucht Konfiguration: den Scanner beibringen, wie man einloggt, wie man eine gültige Session erkennt, und wie man sich nicht selbst ausloggt. Die Investition in diese Konfiguration ist, was einen Scan, der echte Probleme findet, von einem trennt, der einen ordentlichen, irreführend-sauberen Report produziert.
Umfang ist genauso wichtig in die andere Richtung. Ein aktiver Scanner sendet echte Angriffsnutzlasten, die Daten erstellen, Aktionen triggern oder ein System belasten können. Du musst Scans auf autorisierte Ziele — dein Staging oder ausdrücklich-permittierte Umgebungen — beschränken und absichtlich über die Durchführung aktiver Scans gegen Production sein. Scanner-Systeme, die du nicht besitzt oder die Berechtigung zum Testen hast, ist illegal, und die Macht, die diese Tools zur Verteidigung wertvoll macht, macht sie gefährlich bei Missbrauch. Definiere den Umfang, erhalte Autorisierung und bevorzuge Staging für die aggressiven Scans.
Handling moderner Apps: SPAs und APIs
Eine Herausforderung, die das klassische DAST-Modell nicht antizipiert hat, ist, dass ein großer Anteil der 2026-Web-Anwendungen nicht Server-gerenderte Seiten sind, die ein Crawler durch Folgen von Links gehen kann. Sie sind Single-Page Applications (SPAs), in denen der Browser JavaScript ausführt, um die Schnittstelle zu bauen und Daten von APIs abzurufen, und Headless-APIs ohne HTML-Frontend überhaupt. Beides bricht einen naiven Spider: Es gibt keine <a href>-Links zum Folgen, und die reale Angriffsfläche ist ein Satz von API-Endpoints, die von Client-seitigem Code aufgerufen werden. Ein Scanner, der nur traditionelles HTML-Crawling versteht, wird fast keine einer solchen Anwendung mappen und ein beruhigend leeres, völlig irreführendes Ergebnis melden.
Die Tools sind angepasst, und die richtige Mode zu verwenden ist wichtig. Für SPAs, ZAPs Ajax Spider fährt einen echten Browser, um das JavaScript auszuführen und die Requests zu beobachten, die die App tatsächlich macht, und entdeckt die API-Aufrufe, die ein Plain-Spider vermisst würde. Für APIs direkt ist der bessere Pfad, das Crawling ganz zu überspringen und dem Scanner eine Spezifikation zu füttern: ZAPs API-Scan konsumiert eine OpenAPI (Swagger), SOAP oder GraphQL-Definition und testet jeden dokumentierten Endpoint und Parameter systematisch. Das ist oft gründlicher als Crawling, da die Spec die vollständige Oberfläche aufzählt statt auf Entdeckung zu verlassen. Die praktische Regel ist, dem Scanner eine Karte zu geben, wenn du eine hast — eine OpenAPI-Datei, eine Postman-Sammlung, ein GraphQL-Schema — statt zu hoffen, dass es sich seinen Weg zur vollständigen Abdeckung crawlt.
Das rerahmt auch, wo DAST in modernen Development passt. Wenn die Anwendung API-first ist, wird DAST zu API-Sicherheits-Testing, und die Integration der API-Spec in die Scan-Pipeline ist der höchste Leverage-Konfigurations-Schritt. Ein Team, das eine REST oder GraphQL-API versendet, sollte seine OpenAPI/Schema in den ZAP-API-Scan in CI verdrahten, damit jeden Endpoint auf jeder Änderung getestet wird. Die Spezifikation als das Scan-Ziel zu behandeln statt die gerenderte UI ist wie DAST effektiv bleibt, wenn Anwendungen weg von Server-gerenfertem HTML bewegen.
Die Unterlinie
Dynamische Anwendungssicherheitstests erfasst die Anfälligkeiten, die nur existieren, wenn deine Anwendung tatsächlich laufen, und in 2026 deckt der quelloffene DAST-Stack das ganze Range für free — wenn du es als geschichtete Set statt Wetten auf ein Tool nutzt. Laufe Nuclei für schnelle, kontinuierliche Bekannte-CVE und Expositions-Erkennung; Laufe ZAP als dein Vollkern-Crawling-und-Aktiv-Scanning-Arbeitstier mit erstklassiger CI-Automatisierung; füge Wapiti für leichte Command-Line-Fuzzing und Nikto für Server-Konfigurations-Hygiene hinzu. Schichte die schnellen Checks auf jedem Deploy und die tiefen Scans auf einem Zeitplan, investiere in authentifiziertes Scanning damit du die Oberfläche testest, die zählt, Begrenze aktive Scans auf autorisierte Ziele, und du drehst "wir hoffen die App ist sicher" in "wir testen sie gegen echte Angriffe kontinuierlich."
Referenzen und Ressourcen
Tools
Hintergrund und Analyse
- Nuclei-Alternativen 2026: Schnellere Anfälligkeits-Scanner — AppSec Santa
- Vergleichen von Quelloffenen DAST-Tools — ZAP, Nuclei, Wapiti, Nikto
- Beste kostenlose DAST-Tools in 2026
Verwandte 1337skills-Spickzettel