Web und API
Sicherheitstests für Websites und APIs: DAST erklärt
Sicherheitstests für Websites und APIs, oft dynamische Anwendungssicherheitstests (DAST) genannt, senden gezielt präparierte Anfragen an eine laufende Anwendung und beobachten, wie sie reagiert, um Lücken wie fehlerhafte Zugriffskontrolle, Injection und Fehlkonfigurationen zu finden. Sie ergänzen Code- und Abhängigkeitsscans und dürfen nur gegen Systeme laufen, die Ihnen gehören oder für die Sie eine schriftliche Erlaubnis zum Testen haben.
Free-Tarif, keine Kreditkarte erforderlich.
Was sind dynamische Anwendungssicherheitstests (DAST)?
Dynamische Tests behandeln die Anwendung als Blackbox oder, wenn die testende Person Zugangsdaten hat, als Graybox. Ein Tool oder eine Person crawlt die Website oder liest die API-Beschreibung und sendet dann Anfragen, die Fehler provozieren sollen: veränderte Kennungen, unerwartete Parameter, übergroße Payloads, fehlende oder gefälschte Tokens. Befunde entstehen aus dem Verhalten, nicht aus dem Quellcode. Darin liegen Stärke und Grenze der Methode zugleich: Sie sieht, was ein Angreifer sieht, einschließlich Problemen bei Deployment und Konfiguration, findet aber nur, was sie erreicht.
Bei APIs hängt die Abdeckung davon ab, die Endpunkte zu kennen. Eine OpenAPI-Beschreibung, eine Postman-Collection oder aufgezeichneter Datenverkehr lässt einen Test Operationen erreichen, die ein Crawler nie finden würde. Authentifizierte Tests mit mindestens zwei Konten in unterschiedlichen Rollen decken die Lücke auf, die in den OWASP API Security Top 10 ganz oben steht: Ein Nutzer greift auf die Objekte eines anderen Nutzers zu.
Wie unterscheidet sich DAST von SAST und Abhängigkeitsscans?
Die drei Methoden beantworten unterschiedliche Fragen. Abhängigkeitsscans sagen Ihnen, ob die Komponenten, die Sie ausliefern, bekanntermaßen verwundbar sind. Statische Analyse sagt Ihnen, ob Ihr eigener Code gefährliche Muster enthält. Dynamische Tests sagen Ihnen, ob sich das deployte System mit seiner Konfiguration, Authentifizierung und Infrastruktur tatsächlich missbrauchen lässt. Ein ausgereiftes Programm nutzt alle drei und bestätigt mit dynamischen Ergebnissen, welche statischen und Abhängigkeitsbefunde in der Praxis ausnutzbar sind.
| Methode | Was sie untersucht | Typische Befunde | Blinde Flecken |
|---|---|---|---|
| Abhängigkeitsscan | Lockfiles, Manifeste, SBOMs und Container-Images | Bekannte Schwachstellen und schädliche Pakete in Komponenten Dritter | Lücken in Ihrem eigenen Code und in der Art, wie die Anwendung deployt ist |
| Statische Analyse (SAST) | Ihren Quellcode, ohne ihn auszuführen | Injection-Muster, unsichere Funktionen, fest codierte Zugangsdaten | Laufzeitkonfiguration und Autorisierungslogik, die über mehrere Dienste verteilt ist |
| Dynamische Tests (DAST) | Die laufende Website oder API, über das Netzwerk | Fehlerhafte Zugriffskontrolle, Injection, Fehlkonfiguration, offen erreichbare Endpunkte | Codepfade, die der Test nicht erreicht, und die eigentliche Ursache im Code |
Warum Tests auf eigene oder freigegebene Domains beschränken?
Ein Sicherheitstest und ein Angriff sehen auf der Leitung gleich aus; der Unterschied ist die Erlaubnis. In der EU verpflichtet die Richtlinie 2013/40/EU die Mitgliedstaaten, zumindest wenn kein leichter Fall vorliegt, den rechtswidrigen Zugang zu Informationssystemen und den rechtswidrigen Systemeingriff unter Strafe zu stellen, wenn sie vorsätzlich und „unbefugt“ begangen werden. Die Richtlinie definiert das als Verhalten, das vom Eigentümer oder einem anderen Rechtsinhaber des Systems nicht gestattet wurde oder nach nationalem Recht nicht zulässig ist. Die nationalen Gesetze unterscheiden sich im Detail, aber die Arbeitsregel ist überall dieselbe: keine schriftliche Erlaubnis, kein Test.
Die Erlaubnis hat auch technische Seiten. Eine Website bei einem Shared Hoster, hinter einem Content Delivery Network oder hinter einem API-Gateway eines Drittanbieters betrifft weitere Eigentümer, deren Bedingungen Tests einschränken können, und ein Test, der einen gemeinsam genutzten Dienst überlastet, kann anderen Kunden schaden. Die Kontrolle über eine Domain nachzuweisen, etwa mit einem DNS-Eintrag oder einer Datei auf dem Webserver, ist ein gängiger Weg für einen Testdienst, um zu bestätigen, dass die anfragende Person sie testen darf. Bewahren Sie Erlaubnis, Umfang, Testfenster und Ansprechperson zusammen mit den Ergebnissen auf.
Welche OWASP-Listen sollten Website- und API-Tests abdecken?
Die OWASP Top 10 und die OWASP API Security Top 10 sind die üblichen Bezugspunkte, um den Umfang eines Tests festzulegen. Sie sind Dokumente zur Sensibilisierung und keine vollständigen Teststandards, benennen aber die Klassen von Lücken, auf die es am meisten ankommt. Die aktuellen Ausgaben sind die OWASP Top 10:2025 für Webanwendungen und die OWASP API Security Top 10 2023 für APIs.
Mehrere Kategorien findet man mit dynamischen Tests allein nicht. Fehler in der Software-Lieferkette sind weitgehend eine Frage von Abhängigkeiten und Builds, und mangelhaftes Inventarmanagement beginnt damit, zu wissen, welche API-Versionen und Hosts Sie betreiben. Genau dort schließen Scans auf der Codeseite und ein genaues Inventar die Lücke.
| Rang | OWASP Top 10:2025 | OWASP API Security Top 10 2023 |
|---|---|---|
| 1 | Broken Access Control | Broken Object Level Authorization |
| 2 | Security Misconfiguration | Broken Authentication |
| 3 | Software Supply Chain Failures | Broken Object Property Level Authorization |
| 4 | Cryptographic Failures | Unrestricted Resource Consumption |
| 5 | Injection | Broken Function Level Authorization |
| 6 | Insecure Design | Unrestricted Access to Sensitive Business Flows |
| 7 | Authentication Failures | Server Side Request Forgery |
| 8 | Software or Data Integrity Failures | Security Misconfiguration |
| 9 | Security Logging and Alerting Failures | Improper Inventory Management |
| 10 | Mishandling of Exceptional Conditions | Unsafe Consumption of APIs |
Wie passen Web- und API-Tests zu CRA und NIS2?
Nach der Cyberresilienz-Verordnung (Cyber Resilience Act, CRA) umfasst ein Produkt mit digitalen Elementen auch seine Datenfernverarbeitungslösungen: eine Datenverarbeitung aus der Ferne, deren Software vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt wurde und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte. Die Erwägungsgründe des CRA nennen als Beispiel eine mobile App, die eine vom Hersteller bereitgestellte API benötigt; diese API fällt in den Anwendungsbereich, Websites, die die Funktionalität eines Produkts nicht unterstützen, dagegen nicht. Anhang I Teil II verlangt, die Sicherheit des Produkts wirksam und regelmäßig zu testen und zu überprüfen, was bei einem Produkt mit Cloud-Backend vernünftigerweise auch Tests seiner API umfassen kann.
Software, die ausschließlich als Dienst angeboten wird, fällt nicht unter den CRA; die Erwägungsgründe des CRA verweisen für Cloud-Computing-Dienste wie Software as a Service auf NIS2. Artikel 21 Absatz 2 Buchstabe e der NIS-2-Richtlinie verlangt von wesentlichen und wichtigen Einrichtungen Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung ihrer Systeme, einschließlich Management und Offenlegung von Schwachstellen. Für bestimmte Anbieter digitaler Dienste ergänzt die Durchführungsverordnung (EU) 2024/2690 ein dokumentiertes Konzept für Sicherheitsprüfungen, Prüfungen, deren Notwendigkeit, Umfang, Häufigkeit und Art sich aus der Risikobewertung ergeben, und Aufzeichnungen zu Art, Umfang, Zeitpunkt und Ergebnissen jeder Prüfung.
Heute in KROMSE verfügbar
KROMSE testet noch keine laufenden Websites oder APIs, prüft aber den Code, die Abhängigkeiten und die Container-Images dahinter.
- Abhängigkeitsprüfungen gegen OSV.dev für die Lockfiles und Manifeste hinter Ihrer Website oder API, darunter npm, Yarn, pnpm, Poetry, uv, pip, Go, Cargo, Maven, Gradle, Composer, Bundler und .NET.
- Quellcodeanalyse für 11 Sprachen, darunter JavaScript, TypeScript, Python, Java, Go und C#, sowie Import Ihrer eigenen SARIF-2.1.0-Ergebnisse.
- Erkennung von Secrets im gescannten Commit; Secret-Werte werden geschwärzt und nie gespeichert.
- Prüfung von Terraform-Dateien und Dockerfiles auf Fehlkonfigurationen.
- Container-Images in einer aus dem Internet erreichbaren Registry, analysiert auf Schwachstellen, Fehlkonfigurationen und Secrets.
- Pakete, die in der Datenbank OpenSSF Malicious Packages stehen, werden als kritisch markiert; Abhilfe ist das Entfernen.
Als Nächstes geplant
Auf der Roadmap, noch nicht verfügbar. Die Termine sind Zielmarken, keine Zusagen; diese Seite wird an dem Tag aktualisiert, an dem eine Funktion live geht.
- Geplant · Q4 2026 (Dezember)Website- und API-Tests. KROMSE wird Websites und APIs auf Schwachstellen testen, ausschließlich auf Domains, bei denen Sie nachgewiesen haben, dass Sie sie kontrollieren.
- Geplant · Q4 2026 (Dezember)Überwachung nach Ihrem Zeitplan, mit KI-Agenten. Erneute Scans werden nach einem Zeitplan laufen, den Sie festlegen, mit KI-Agenten, die neue Sicherheitshinweise verfolgen, einordnen, was davon zutrifft, Korrekturen vorschlagen und den Bericht zu Ihrer Prüfung entwerfen.
Häufige Fragen
Testet KROMSE Websites und APIs?
Noch nicht. KROMSE führt heute keine dynamischen Tests gegen Websites oder APIs aus. Es prüft, was dahinter steckt: Abhängigkeiten, Quellcode in 11 Sprachen, eingecheckte Secrets, Fehlkonfigurationen in Terraform-Dateien und Dockerfiles sowie Container-Images. Sicherheitstests für Websites und APIs auf Domains, deren Kontrolle Sie nachgewiesen haben, stehen auf der Roadmap, und diese Seite ändert sich, sobald sie verfügbar sind.
Ist es legal, eine Website zu scannen, die mir nicht gehört?
In der Regel nicht ohne Erlaubnis. Die Richtlinie 2013/40/EU verpflichtet die EU-Mitgliedstaaten, den vorsätzlichen und unbefugten Zugang zu Informationssystemen und Eingriffe in sie unter Strafe zu stellen, also ohne Erlaubnis des Eigentümers oder eines anderen Rechtsinhabers, zumindest wenn kein leichter Fall vorliegt. Die nationalen Gesetze ergänzen eigene Regeln. Testen Sie nur Systeme, die Ihnen gehören oder für die Sie eine schriftliche Erlaubnis haben, und beachten Sie die Bedingungen aller beteiligten Hosting-, CDN- oder API-Anbieter.
Was ist der Unterschied zwischen DAST und einem Penetrationstest?
DAST ist meist automatisiert: Ein Tool sendet viele Anfragen und meldet Verhalten, das bekannten Mustern von Lücken entspricht. Ein Penetrationstest wird von einem Menschen geführt, der Befunde verkettet, Geschäftslogik testet und die Auswirkungen beurteilt, oft mit DAST-Tools als Hilfsmittel. Automatisierte Tests eignen sich für häufige, wiederholbare Prüfungen; ein Penetrationstest für größere Releases, wesentliche Änderungen und Systeme mit hohem Risiko.
Verlangt der CRA Sicherheitstests für die API meines Produkts?
Der CRA schreibt keine Testmethode vor. Anhang I Teil II verlangt, die Sicherheit des Produkts wirksam und regelmäßig zu testen und zu überprüfen, und zu einem Produkt gehören seine Datenfernverarbeitungslösungen, etwa eine API, ohne die Ihre App nicht funktioniert. Wählen Sie die Methoden, die Ihre Risikobewertung rechtfertigt, und halten Sie Testumfang, Methode und Ergebnisse in Ihrer technischen Dokumentation fest.
Welche OWASP-Liste sollte ich für APIs verwenden?
Die OWASP API Security Top 10, deren aktuelle Ausgabe von 2023 stammt. Sie konzentriert sich auf API-spezifische Lücken wie Broken Object Level Authorization, Broken Authentication, Unrestricted Resource Consumption und Improper Inventory Management, die weborientierte Listen weniger direkt abdecken. Nutzen Sie sie zusammen mit den OWASP Top 10:2025 für das Web-Frontend.