Penetration Test für Web-Anwendungen: Ablauf, Nutzen und typische Schwachstellen

„Wir haben einen Security-Scan laufen lassen, war grün" — und drei Monate später ist trotzdem ein Datensatz abgeflossen, den jeder eingeloggte Nutzer über eine geänderte URL hätte sehen können.

Das ist kein erfundenes Szenario, sondern das häufigste Missverständnis: Ein automatischer Scan und ein Penetrationstest sind nicht dasselbe. Dieser Artikel erklärt den Unterschied, den Ablauf eines echten Pentests, die typischen Lücken und wann er sich lohnt.

Scan, Pentest, Code-Review, Audit — vier verschiedene Dinge

Automatischer Scan: Ein Tool prüft bekannte Muster (veraltete Bibliotheken, fehlende Header). Schnell, günstig, findet das Offensichtliche — aber keine Logikfehler.
Penetrationstest: Ein Mensch greift die Anwendung gezielt an wie ein realer Angreifer: Rollen umgehen, Berechtigungen austricksen, Eingaben missbrauchen, Geschäftslogik aushebeln. Findet genau das, was Scanner nicht sehen.
Code-Review: Sicht in den Quellcode statt nur auf die laufende App. Findet Ursachen, nicht nur Symptome.
Sicherheitsaudit: Bewertet Prozesse, Konfiguration und Organisation, nicht nur Technik.

Ein Scanner sagt „dieses Schloss ist ein bekanntes Modell". Ein Pentester prüft, ob Ihre Tür mit Ihren Schlüsseln, Rollen und Sonderfällen tatsächlich hält.

Der Ablauf eines Pentests

Ein seriöser Penetrationstest ist strukturiert, nicht chaotisches Herumprobieren:

Scoping. Was wird getestet (Web-App, API, Login, Rollen), aus welcher Perspektive (ohne Account, als Nutzer, als Admin), und was ist ausdrücklich tabu (Produktion vs. Staging, Lasttests).
Aufklärung. Angriffsfläche kartieren: Endpunkte, Parameter, Rollen, Datenflüsse.
Ausnutzung. Gezielte Angriffe auf Zugriffskontrolle, Authentifizierung, Eingaben, Konfiguration und Geschäftslogik.
Nachweis. Jede Lücke wird reproduzierbar dokumentiert — mit Schritten, Auswirkung und Risiko, nicht nur „Finding XY".
Bericht & Nachtest. Priorisierte Befunde, konkrete Empfehlungen, und ein Re-Test, der prüft, ob die Behebung wirklich greift.

Der Wert liegt im letzten Schritt: Ein Pentest ohne Nachtest ist eine Momentaufnahme, kein Sicherheitsgewinn.

Die typischen Lücken: OWASP Top 10

Die OWASP Top 10 (2021) sind die anerkannte Referenz für Web-Risiken. Auf Platz 1 steht seit 2021 — und in der Fortschreibung weiterhin — Broken Access Control: Nutzer können auf Daten oder Aktionen zugreifen, die ihnen nicht zustehen. In der OWASP-Auswertung wurden 94 % der getesteten Anwendungen auf eine Form von fehlerhafter Zugriffskontrolle getestet.

Die wiederkehrenden Muster im Mittelstand:

Broken Access Control (A01): Fremde Datensätze über manipulierte IDs/URLs, API-Endpunkte ohne Rechteprüfung, „im Menü ausgeblendet" als Sicherheitskonzept.
Cryptographic Failures (A02): Sensible Daten unverschlüsselt oder schwach geschützt.
Injection (A03): Eingaben werden als Befehl interpretiert (SQL, Befehle, auch in KI-Features als Prompt Injection — siehe Prompt Injection verstehen).
Security Misconfiguration (A05): Standardpasswörter, offene Debug-Endpunkte, zu großzügige Rechte.
Vulnerable Components (A06): Veraltete Bibliotheken mit bekannten Lücken.
Logging/Monitoring Failures (A09): Ein erfolgreicher Angriff fällt nicht auf, weil niemand mitschreibt.

Der mit Abstand häufigste reale Schaden im KMU-Kontext ist A01 — und genau das findet kein Scanner zuverlässig, weil es Logik ist, kein Muster.

Wann sich ein Pentest lohnt

Nicht jede Anwendung braucht jährlich einen vollen Pentest. Aber es gibt klare Auslöser:

Vor dem Go-Live einer Anwendung mit personenbezogenen oder geschäftskritischen Daten.
Nach einer größeren Änderung an Authentifizierung, Rollen oder Zahlungslogik.
Wenn ein Kunde, Partner oder Versicherer es vertraglich verlangt.
Bei regulatorischer Relevanz (DSGVO-sensible Verarbeitung).
Wenn die App externe Inhalte verarbeitet oder Aktionen automatisiert auslöst.

Der Lagebericht des BSI zur IT-Sicherheit in Deutschland ordnet die Bedrohungslage als anhaltend hoch ein; die ENISA-Threat-Landscape bestätigt webbasierte Angriffe als Dauerthema. Sicherheit ist kein Projektende, sondern ein wiederkehrender Zustand.

Was ein guter Pentest-Bericht enthält

Priorisierte Befunde nach realem Risiko, nicht nach Tool-Score.
Für jede Lücke: Reproduktion, Auswirkung, Empfehlung.
Eine Management-Zusammenfassung (was bedeutet das fürs Geschäft) und ein technischer Teil.
Ein vereinbarter Nachtest nach Behebung.

Ein Bericht, der nur eine Liste von „Findings" mit CVSS-Zahlen ist, hilft niemandem bei der Entscheidung, was zuerst zu tun ist.

Checkliste vor der Beauftragung

Ist der Scope klar (Was, aus welcher Rolle, Staging vs. Produktion)?
Wird manuell getestet, nicht nur gescannt?
Wird Geschäftslogik und Zugriffskontrolle geprüft, nicht nur Header?
Ist ein Nachtest Teil des Angebots?
Bekommen wir einen priorisierten, verständlichen Bericht — nicht nur einen Tool-Export?
Ist klar, wer die Befunde behebt und wer es verifiziert?

Häufige Fragen

Reicht ein automatischer Scan nicht? Für bekannte, oberflächliche Probleme ja. Für Zugriffskontrolle und Geschäftslogik — die häufigsten realen Schäden — nein. Beides ergänzt sich; eines ersetzt das andere nicht.

Pentest auf Produktion oder Staging? Bevorzugt auf einer produktionsnahen Staging-Umgebung mit echten Datenstrukturen, ohne echte personenbezogene Daten. Produktion nur mit klaren Regeln.

Wie oft? Vor relevanten Releases und nach größeren Änderungen an Auth/Rollen/Zahlung — nicht starr „einmal im Jahr", sondern ereignisgetrieben.

Was kostet das? Wie bei Software: abhängig von Scope. Ein klar abgegrenzter Test einer App mit Login und drei Rollen ist kalkulierbar; „testet mal alles" ist es nicht.

Fazit

Ein Penetrationstest ist kein grünes Häkchen, sondern ein kontrollierter Angriff durch einen Menschen — genau dort, wo Scanner blind sind: Zugriffskontrolle, Rollen, Geschäftslogik. Strukturierter Ablauf, OWASP-orientierte Tiefe und ein Nachtest trennen einen echten Pentest von einem teuren Scan mit Bericht.

Weiterlesen

Prompt Injection verstehen: Warum KI-Anwendungen eigene Security-Checks brauchen — die Schwester-Risikoklasse für KI-Features.
DSGVO-konforme KI-Anwendungen — Sicherheit und Datenschutz gehören zusammen geplant.

Nächster Schritt

Vor dem Go-Live oder nach einer Änderung an Rollen und Auth? Sprechen Sie mit uns über einen klar geschnittenen Penetrationstest und Security-Review mit priorisiertem Bericht und Nachtest.

Quellen

OWASP, Top 10:2021 Web Application Security Risks — owasp.org
OWASP, A01:2021 Broken Access Control — owasp.org
BSI, Die Lage der IT-Sicherheit in Deutschland — bsi.bund.de
ENISA, Threat Landscape — enisa.europa.eu