Die häufigsten Schwachstellen in Webanwendungen und APIs bei Penetrationstests

Webanwendungen sind mit großem Abstand der häufigste Projekttyp. Im Jahr 2025 führten wir 345 Penetrationstests von Webanwendungen durch. Das entspricht etwa 55 % aller Aufträge. Gleichzeitig entfiel auf sie die höchste Zahl an Funden: 1.347 Schwachstellen, darunter 63 kritische und 119 Schwachstellen mit hohem Schweregrad.

Die durchschnittliche Zahl der Funde pro Projekt lag mit etwa 3,9 jedoch unter den Werten für Infrastruktur- und Cloud-Projekte. Webanwendungen verursachten somit das größte Gesamtvolumen an Funden, wiesen aber einen niedrigeren durchschnittlichen Schweregrad auf.

Am häufigsten handelt es sich um unzureichende Zugriffskontrollen (Broken Access Control), Injection-Schwachstellen und Fehler bei der Authentifizierung. Dies bestätigt auch die aktualisierte OWASP Top 10:2025. Broken Access Control bleibt auf dem ersten Platz und umfasst nun auch Angriffe vom Typ SSRF.

Wie sieht das in der Praxis aus? Beim Test einer Webanwendung für Kunden mussten wir lediglich eine einzige Zahl in der URL ändern – die Kennung einer Bestellung. Anstelle der eigenen Bestellung zeigte die Anwendung die Bestellung eines anderen Kunden an, einschließlich Name, Adresse und bestellter Artikel.

Dafür waren weder ein Exploit noch ein spezielles Tool erforderlich. Die Anwendung prüfte schlicht nicht, ob der angemeldete Benutzer auf das angeforderte Objekt zugreifen durfte. Das ist Broken Access Control in der Praxis und zugleich die häufigste kritische Schwachstelle, die wir in Webanwendungen finden.

Das Jahr 2025 brachte jedoch auch eine neue Erkenntnis: Das Framework selbst kann zur Schwachstelle werden. React2Shell (CVE-2025-55182), ein Deserialisierungsfehler in React Server Components und Next.js, erreichte mit 10.0 den maximalen CVSS-Wert. Angreifer begannen bereits wenige Tage nach der Veröffentlichung, die Schwachstelle auszunutzen. Im Dezember wurde sie in den CISA-KEV-Katalog aufgenommen.

Die gleiche Entwicklung beobachten wir bei unseren Penetrationstests. Immer häufiger gelangen wir nicht über einen Fehler in der Anwendung selbst in ein System, sondern über ihr Umfeld: einen offengelegten API-Schlüssel in einem Repository, ein vergessenes Testkonto oder eine verwundbare Bibliothek eines Drittanbieters. Die Anwendung kann gut entwickelt sein, vertraut jedoch einer Komponente, die es nicht ist.

Wenn ein Unternehmen mit Hunderten von Lieferanten zusammenarbeitet, ist es unrealistisch, jeden einzelnen zu auditieren. Praktikabler ist es, aktuelle Sicherheitsberichte zu verlangen, Zugangsdaten mit begrenzter Gültigkeit und regelmäßiger Rotation zu verwenden und laufend zu überwachen, auf welche Systeme und Daten die einzelnen Integrationen tatsächlich zugreifen können.

API-Schwachstellen: weniger sichtbar, aber umso gefährlicher

Bei 48 API-Projekten identifizierten wir 145 Funde, also durchschnittlich drei Schwachstellen pro Projekt. Das vorherrschende Risiko ist seit Jahren unverändert: Broken Object Level Authorization (BOLA) steht gemäß den OWASP API Security Top 10 weiterhin an erster Stelle.

Dabei handelt es sich um denselben Fehler wie im vorherigen Beispiel, nur eine Ebene tiefer. Während die Benutzeroberfläche das Objekt eines anderen Benutzers nicht anzeigt, gibt die zugrunde liegende API es bei einer direkten Anfrage bereitwillig zurück. Obwohl laut Salt Security 99 % der Unternehmen bereits mindestens einen API-Sicherheitsvorfall erlebt haben, können nur wenige alle betriebenen APIs vollständig erfassen.

Was bedeutet das für CISOs?

Webanwendungen bilden eine ausgereifte, aber sich ständig verändernde Angriffsfläche. Kontinuierliche Tests schaffen hier einen größeren Mehrwert als einmalige, umfassende Audits. Für APIs gilt eine einfache Regel: Was Sie nicht kennen, können Sie nicht schützen.

Daher lohnt es sich, in API Discovery, Autorisierung auf Objektebene und serverseitige Sicherheitskontrollen zu investieren.