Sicherheitstests für Webanwendungen: Der vollständige Leitfaden

Wenn Ihre Webanwendung Logins, Zahlungen oder Kundendaten verarbeitet, wird Sie früher oder später jemand bitten, ihre Sicherheit nachzuweisen: der Sicherheitsfragebogen eines Enterprise-Kunden, ein Auditor oder Ihr eigener Vorstand, nachdem ein Sicherheitsvorfall in Ihrer Branche Schlagzeilen gemacht hat. Eine glaubwürdige Antwort beginnt mit dem Wissen, woraus Sicherheitstests für Webanwendungen tatsächlich bestehen und für welche Teile Sie bezahlen, wenn Sie sie intern durchführen oder Sicherheitstest-Dienstleistungen einkaufen.

Sicherheitstests für Webanwendungen finden ausnutzbare Schwachstellen in einer Web-App, bevor Angreifer es tun. Sie kombinieren vier Ansätze: statische Analyse des Quellcodes (SAST), dynamisches Testen der laufenden App von außen (DAST), instrumentiertes Testen aus dem Inneren der App zur Laufzeit (IAST) und manuelle Penetrationstests. Jeder Ansatz erkennt eine andere Klasse von Schwachstellen, deshalb setzt ein wirksames Programm mehrere davon ein.

Die wichtigste Kostenentscheidung ist die Reihenfolge. Einmal eingerichtet, kosten automatisierte SAST- und DAST-Scans pro Durchlauf wenig und können bei jedem Build oder jede Nacht laufen. Ein manueller Penetrationstest einer mittelgroßen Web-App beansprucht in der Regel ein bis drei Wochen Spezialistenzeit. Damit ist er die teure Ebene, die Sie bewusst einplanen sollten. Wer die Reihenfolge falsch wählt, bezahlt Penetrationstester meist dafür, Probleme zu finden, die ein kostenloser Scanner erkannt hätte.

Im Folgenden erfahren Sie, was jeder Ansatz leistet, wo seine Grenzen liegen und wann Sie welchen brauchen.

Die 4 Testansätze: SAST, DAST, IAST und Pentests

Die vier Ansätze unterscheiden sich darin, was sie untersuchen und wann sie laufen. SAST liest den Code, bevor er ausgeliefert wird, DAST und IAST testen die Anwendung im laufenden Betrieb, und beim Penetrationstest tritt ein menschlicher Angreifer gegen sie an. Jeder Ansatz hat blinde Flecken, die die anderen abdecken. Deshalb setzen ausgereifte Programme alle vier an unterschiedlichen Punkten im Release-Zyklus ein.

Statische Anwendungssicherheitstests (SAST)

SAST scannt Quellcode, Bytecode oder Binärdateien, ohne die Anwendung auszuführen. Es verfolgt, wie Daten von Benutzereingaben zu sensiblen Operationen fließen, und markiert Muster wie unbereinigte Eingaben, die in eine Datenbankabfrage gelangen, fest codierte Secrets und schwache Kryptografie. SAST kann in der IDE eines Entwicklers oder bei jedem Pull Request laufen und zeigt auf die genaue Datei und Zeile.

Seine Grenze ist der Kontext. SAST sieht nicht, wie die App konfiguriert oder bereitgestellt ist, und markiert oft Codepfade, die in der Praxis gar nicht erreichbar sind. Der erste Scan einer bestehenden Codebasis liefert daher meist eine lange Liste, die jemand sichten und bewerten muss.

Die Software Composition Analysis (SCA) läuft meist parallel zu SAST und prüft Bibliotheken von Drittanbietern auf bekannte Schwachstellen, also das Risiko hinter verwundbaren und veralteten Komponenten.

Dynamische Anwendungssicherheitstests (DAST)

DAST testet die laufende Anwendung von außen, so wie ein Angreifer, ohne Zugriff auf den Code. Ein Scanner durchsucht die App, sendet präparierte Anfragen an jede gefundene Eingabe und wertet die Antworten auf Anzeichen von Injection, Cross-Site Scripting (XSS), fehlenden Security-Headern, offen zugänglichen Dateien und falsch konfigurierten Servern aus.

DAST findet Probleme, die erst nach dem Deployment existieren: Server- und TLS-Konfiguration, Cookie-Flags, Fehlerseiten, die Stacktraces preisgeben. Schwächer ist es bei allem, was ein Crawler nicht erreicht, etwa Seiten hinter mehrstufiger Authentifizierung oder Routen von Single-Page-Apps, die erst nach der Ausführung von JavaScript erscheinen. Findet DAST ein Problem, meldet es eine URL, und die Entwickler müssen die zugehörige Codestelle noch selbst finden.

Interaktive Anwendungssicherheitstests (IAST)

IAST platziert einen Agenten in der laufenden Anwendung, in der Sprach-Runtime oder im Anwendungsserver, und beobachtet, was der Code tut, während die App genutzt wird. Wenn eine Testanfrage Eingaben in eine SQL-Abfrage oder einen Dateipfad trägt, sieht der Agent sowohl die Anfrage als auch die genaue Codezeile, die sie verarbeitet hat.

Damit verbindet IAST die Laufzeitsicht von DAST mit der Präzision von SAST auf Codeebene, meist mit weniger False Positives als beide. Der Haken ist die Abdeckung: IAST analysiert nur Codepfade, die tatsächlich ausgeführt werden. Sein Nutzen hängt also von der Qualität der Funktions- und Regressionstests ab, die die App durchlaufen. Außerdem braucht es einen Agenten, der Ihre Sprache und Ihr Framework unterstützt, und es erzeugt etwas Overhead in der Testumgebung, in der es läuft.

Manuelle Penetrationstests

Bei einem Penetrationstest versucht ein Sicherheitsspezialist aktiv, in die Anwendung einzudringen, und verfolgt dabei die Ziele eines echten Angreifers: die Daten eines anderen Kunden lesen, ein normales Konto zum Admin machen oder einen Zahlungsschritt überspringen. Tester nutzen Scanner für die Abdeckung und verbringen dann den Großteil ihrer Zeit mit dem, was Tools nicht beurteilen können, etwa zwei Befunde mit niedrigem Schweregrad zu einem schwerwiegenden zu verketten oder einen Workflow zu missbrauchen, der technisch gültig ist, aber nie erlaubt sein sollte.

Von den vier Ansätzen deckt nur der Penetrationstest Autorisierungsfehler und den Missbrauch von Geschäftslogik zuverlässig auf, und er liefert Nachweise, die ein Kunde oder Auditor akzeptiert. Gleichzeitig ist er eine Momentaufnahme und pro Befund die teuerste Ebene. Je nachdem, wie viel der Tester vorab weiß, läuft ein Pentest als Black-Box-, Grey-Box- oder White-Box-Projekt. Genau so strukturiert QAwerk seine Penetrationstest-Dienstleistungen.

SAST vs. DAST vs. IAST vs. Pentests im Überblick

Wie diese Ansätze zusammenwirken

SAST erkennt Probleme am frühesten, solange die Korrektur eine einzeilige Änderung in einem noch nicht gemergten Branch ist. Das macht es zur günstigsten Ebene. SAST kann Ihnen aber nicht sagen, ob eine markierte Zeile erreichbar ist oder ob der bereitgestellte Server sicher konfiguriert ist.

DAST und IAST erfassen, was sich erst zur Laufzeit zeigt. DAST prüft die App so, wie sie bereitgestellt ist, einschließlich Webserver, TLS-Einstellungen und Response-Headern. IAST bestätigt, welche Datenflussprobleme real sind, indem es sie beim Auftreten beobachtet. Deshalb passt es gut zu einer bestehenden automatisierten Regressionssuite: Die Tests, die bereits Funktionen prüfen, prüfen dann auch die Sicherheit.

Manuelle Penetrationstests decken die Fehlerklasse ab, mit der Automatisierung am schlechtesten zurechtkommt. Ein Scanner kann bestätigen, dass ein Endpunkt einen Login erfordert. Er kann aber nicht erkennen, dass ein eingeloggter Kunde eine Bestell-ID in der URL ändern und die Rechnung einer anderen Person sehen kann. Fehlerhafte Zugriffskontrolle dieser Art steht in den OWASP Top 10:2025 auf Platz eins, und um sie zu finden, braucht es einen Menschen, der versteht, was die App erlauben soll. Wie die manuelle Ebene Bereich für Bereich aussieht, zeigt unsere Checkliste für Penetrationstests von Webanwendungen.

Die OWASP-Testmethodik

Das Open Worldwide Application Security Project (OWASP) veröffentlicht den Web Security Testing Guide (WSTG), den am häufigsten zitierten Standard dafür, wie man die Sicherheit einer Webanwendung testet. Die aktuelle stabile Version 4.2 gliedert aktive Tests in 12 Kategorien:

• Informationsbeschaffung
• Tests des Konfigurations- und Deployment-Managements
• Tests des Identitätsmanagements
• Authentifizierungstests
• Autorisierungstests
• Tests des Session-Managements
• Tests der Eingabevalidierung
• Tests der Fehlerbehandlung
• Tests auf schwache Kryptografie
• Tests der Geschäftslogik
• Clientseitige Tests
• API-Tests

Jede Kategorie enthält nummerierte Testfälle. Die Tests des Session-Managements umfassen zum Beispiel Cookie-Attribute, Session Fixation, Cross-Site Request Forgery, das Logout-Verhalten und Session-Timeouts. Professionelle Pentest-Berichte zitieren oft diese IDs (WSTG-SESS-05 ist der Test auf Cross-Site Request Forgery), sodass sich jeder Befund auf ein dokumentiertes Verfahren zurückführen lässt.

Eine praxistaugliche Zuordnung der WSTG-Kategorien zu den vier Ansätzen:

• Informationsbeschaffung, Konfiguration und clientseitige Tests: weitgehend mit DAST automatisierbar, wobei ein Mensch prüft, was der Scanner markiert.
• Eingabevalidierung und schwache Kryptografie: gut abgedeckt durch SAST im Code sowie durch DAST oder IAST zur Laufzeit.
• Authentifizierung und Session-Management: teilweise automatisierbar, aber Kontosperrung, Passwort-Reset und Session-Timeout erfordern einen Tester, der die Abläufe Schritt für Schritt durchgeht.
• Autorisierung und Geschäftslogik: fast ausschließlich manuelle Penetrationstests.

Der ergänzende Standard, der OWASP Application Security Verification Standard (ASVS), definiert Sicherheitsanforderungen in drei unterschiedlich strengen Stufen. So können Sie entscheiden, wie tief die Tests für Ihre App gehen müssen.

Sicherheitstests für Webanwendungen systematisch aufbauen

Ein Testprogramm folgt dem Softwareentwicklungslebenszyklus (SDLC). Das US-amerikanische National Institute of Standards and Technology (NIST) führt in seinem Secure Software Development Framework, SP 800-218, die Prüfung von menschenlesbarem Code auf Schwachstellen (Praxis PW.7) und das Testen von ausführbarem Code (Praxis PW.8) als zwei getrennte Praktiken auf.

Blockieren Sie Merges nur bei SAST-Befunden mit hohem Schweregrad, sonst lernen die Entwickler, das Tool zu ignorieren. Und testen Sie nach jedem Pentest erneut, denn eine nicht verifizierte Korrektur ist weiterhin ein offener Befund.

Beim Rhythmus starten die meisten Teams mit einem jährlichen Penetrationstest plus einem Retest nach den Korrekturen. Für Anwendungen, die Kartendaten speichern, verarbeiten oder übertragen, schreibt PCI DSS Penetrationstests mindestens alle 12 Monate und nach jeder wesentlichen Änderung vor. Produkte aus Fintech und Healthtech sowie alles, was Ausweisdokumente speichert, werden meist häufiger getestet. Unser Leitfaden zur Häufigkeit von Penetrationstests zeigt, wie Sie diesen Rhythmus für Ihr Risikoprofil festlegen.

Wenn Sie bei null anfangen, bringt diese Reihenfolge die meiste Abdeckung für das geringste Budget:

1. Aktivieren Sie SAST und Dependency-Scanning im Repository.
2. Ergänzen Sie einen DAST-Scan gegen Ihre Staging-Umgebung.
3. Buchen Sie einen klar abgegrenzten Penetrationstest vor Ihrem nächsten größeren Release oder Security-Review.
4. Fügen Sie IAST hinzu, sobald Sie eine automatisierte Regressionssuite haben, deren Instrumentierung sich lohnt.

Wenn Sie das Budget für den dritten Schritt intern begründen müssen, lesen Sie hier, warum Penetrationstests so wichtig sind, gerade für ein Produkt in Ihrer Phase.

Wann ein schlankeres Setup ausreicht

Nicht jede App braucht alle vier Ebenen. Eine Marketing-Website ohne Login, ohne gespeicherte Kundendaten und mit einem einzigen Kontaktformular braucht einen DAST-Scan, eine gehärtete Serverkonfiguration und regelmäßige Updates der Abhängigkeiten. Ein vollständiger Penetrationstest lohnt sich dort kaum. IAST sollten Sie zurückstellen, bis Sie eine solide automatisierte Testabdeckung haben, denn ein Agent, der drei Smoke-Tests beobachtet, analysiert sehr wenig. Ein Penetrationstest an einer App, die noch niemand gescannt hat, verbraucht teure Stunden für Befunde, die ein kostenloses Tool gemeldet hätte.

Die volle Kombination rechnet sich bei jeder App mit mehreren Benutzerrollen, Zahlungen, personenbezogenen oder regulierten Daten oder Enterprise-Kunden, die Sicherheitsfragebögen schicken.

Wie QAwerk Sicherheitstests für Web-Apps durchführt

Bei QAwerk sind Sicherheitstests im selben Team angesiedelt, das auch Funktions- und Regressionstests durchführt. Die QA-Engineers, die die Regressionssuite aufbauen, wissen, welche Abläufe wichtig sind. So decken DAST- und IAST-Läufe die Pfade ab, die echte Nutzer gehen, und die Penetrationstester starten mit bereits erfassten Rollen und Geschäftsregeln. Ein Validation Lead reproduziert jeden Befund und dokumentiert ihn mit Schritten und Nachweisen, damit die Entwickler ihn im nächsten Sprint aufgreifen können.

Wir steigen in jeder Phase ein, in der sich Ihr Produkt gerade befindet, von einer App vor dem Launch, die ihren ersten Pentest braucht, bis zu einem Live-Produkt vor seinem ersten Security-Review durch einen Enterprise-Kunden. Unsere Leistungen umfassen SAST-Code-Reviews sowie Black-, Grey- oder White-Box-Penetrationstests, abgerechnet nach Time & Material mit einer realistischen und einer pessimistischen Schätzspanne pro Aufgabe. QAwerk hat Penetrationstests für Fintech- und Identitätsverifizierungsprodukte durchgeführt, bei denen Autorisierung und Session-Handling am genauesten geprüft werden.

Statische, dynamische und manuelle Tests kombinieren

Kein einzelner Testansatz findet alles. SAST hält fehlerhaften Code früh fern, DAST und IAST zeigen, was zur Laufzeit passiert, und manuelle Penetrationstests finden die Zugriffs- und Logikfehler, die Automatisierung übersieht. Ein echtes Sicherheitsprogramm für Web-Apps setzt jeden dieser Ansätze an seinem eigenen Punkt im SDLC ein. Wenn Sie das von einem einzigen Team planen und umsetzen lassen möchten, sprechen Sie mit uns über die Sicherheit Ihrer Web-App und unsere Testservices für Webanwendungen.

FAQ

Was ist der Unterschied zwischen SAST und DAST?

SAST analysiert Quellcode, ohne ihn auszuführen, und zeigt auf die genaue Zeile eines Fehlers. Deshalb läuft es früh, bei jedem Commit. DAST testet die laufende Anwendung von außen und findet Konfigurations- und Laufzeitprobleme, braucht also einen bereitgestellten Build. Beide erkennen unterschiedliche Probleme, und die meisten Teams nutzen beide.

Ist IAST ein Ersatz für DAST?

IAST ist präziser, sieht aber nur Codepfade, die Ihre Tests ausführen, und braucht einen Agenten, der Ihren Stack unterstützt. DAST prüft weiterhin den bereitgestellten Webserver, die TLS-Einstellungen und die Header. Am besten funktionieren die beiden daher zusammen.

Können automatisierte Scanner einen Penetrationstest ersetzen?

Nein. Scanner sind gut bei bekannten Mustern wie Injection und Fehlkonfigurationen. Sie können nicht beurteilen, ob ein Benutzer einen Datensatz sehen oder einen Workflow-Schritt überspringen darf, und genau dort liegen fehlerhafte Zugriffskontrolle und Fehler in der Geschäftslogik. Um diese zu finden, braucht es einen menschlichen Tester.

Wie oft sollte eine Webanwendung auf Sicherheit getestet werden?

Führen Sie SAST- und Dependency-Scans bei jeder Änderung durch, DAST mindestens einmal pro Release und einen manuellen Penetrationstest mindestens einmal im Jahr sowie nach wesentlichen Änderungen. Apps, die Zahlungen, Gesundheitsdaten oder Ausweisdokumente verarbeiten, brauchen in der Regel häufiger Penetrationstests.

Was ist die OWASP-Testmethodik?

Gemeint ist der Ansatz aus dem OWASP Web Security Testing Guide, der Sicherheitstests für Web-Apps in 12 Kategorien gliedert, von Informationsbeschaffung und Authentifizierungstests bis zu Session-Management, Eingabevalidierung und Geschäftslogik. Tester zitieren die Test-IDs daraus in ihren Berichten.