40 Prozent der APIs haben direkt mehrere Sicherheitslecks

Fast 40 Prozent der APIs sind mehreren Authentifizierungsrisiken ausgesetzt.

Ein Imperva Report 2026 zeigt eine alarmierende Entwicklung bei der Absicherung von Schnittstellen: Fast 40 Prozent aller analysierten APIs weisen mehrere Authentifizierungsrisiken gleichzeitig auf. Security-Experten merzen bekannte Schwachstellen wie schwache Signierungsalgorithmen zunehmend aus, aber kritische Fehler im Systemdesign – wie sensible Daten in JSON Web Tokens (JWTs) oder der Zugriff über bereits abgelaufene Tokens – nehmen zu.

Zusammenfassung (TL; DR):

• Der „Imperva API Security Report 2026“ zeigt, dass fast 40 Prozent aller untersuchten APIs von mehreren Authentifizierungsrisiken gleichzeitig betroffen sind.
• Einfache, checklistengebundene Probleme wie schwache Algorithmen haben abgenommen. Strukturelle Fehler wie das Speichern sensibler Daten in JWTs oder die Weiternutzung abgelaufener Tokens verschlechtert sich.
• Für Sicherheitsteams bedeutet dies, dass das isolierte Beheben einzelner Schwachstellen nicht mehr ausreicht, da Risiken meist gebündelt auf veralteten Endpunkten auftreten.

Im Fokus: JSON Web Tokens (JWTs)

Für ihren Bericht zu Sicherheitsrisiken rund um APIs und Authentifizierung analysierten die Sicherheitsexperten von Thales fünf Risikokategorien im Jahresvergleich von 2025 auf 2026. Im Fokus der Untersuchung standen JSON Web Tokens (JWTs). Die Experten prüften insgesamt 32.725 Tokens nach fünf Kriterien:

• ob sie sensible Daten enthalten,
• ob sie mit schwachen Algorithmen signiert sind,
• ob sie eine übermäßig lange Gültigkeitsdauer besitzen,
• ob die Basic-Authentifizierung mit unverschlüsselten Anmeldedaten noch verwendet wird,
• und ob Tokens auch nach Ablauf ihrer Gültigkeit weiterhin Zugriff gewähren.

Die wichtigste Erkenntnis war, dass Authentifizierungsrisiken in der Regel nicht isoliert auftreten. Bei 13.016 der 32.725 analysierten API-Endpunkte (im Folgenden auch als „Endpunkte“ oder „Routen“ bezeichnet), umgerechnet fast 40 Prozent, wiesen gleichzeitig mehr als nur ein Authentifizierungsrisiko auf. In der Regel betrifft es etwa zwei von fünf Endpunkten.

Endpunkt mit Schwachstelle

Ein Endpunkt, dessen Tokens sensible Daten enthalten, weist zugleich eine Schwachstelle auf, durch die abgelaufene Tokens weiterhin einen unbegrenzten Zugriff ermöglichen. Dieses Sicherheitsrisiko hat im Jahresvergleich um 70 Prozent zugenommen. Im Extremfall ist dies schlimmer als eine Kombination mehrerer Risiken. Der Endpunkt mit dem höchsten Risiko wies alle fünf oben beschriebenen Risikotypen gleichzeitig auf. Endpunkte wie dieser sind in der Regel nicht das Ergebnis von fünf separaten, voneinander unabhängigen Fehlern. Häufiger handelt es sich um einen einzelnen veralteten oder selten genutzten Endpunkt. Hier hat man nie die an aktuelle Sicherheitsstandards angepasst.

Wären diese Risiken zufällig verstreut, wäre eine solche Route ein statistischer Zufall. Stattdessen wiederholt sich das Muster bei fast 40 Prozent aller gemessenen Fälle. Die Herausforderung für Sicherheitsteams ist dadurch systemischer Natur. Die übliche Vorgehensweise, bei der ein Authentifizierungsproblem gefunden, behoben und das Ticket geschlossen wird, führt sehr wahrscheinlich dazu, dass weitere Schwachstellen auf genau demselben Endpunkt unentdeckt bleiben.

Verbesserungsbedarf bei der Cybersicherheit

In der Folge sind die Risiken, die sich in diesem Jahr verbessert haben, auch diejenigen, die leicht zu überprüfen sind. Die Risiken, die sich verschlechtert haben, sind diejenigen, die schwer zu überprüfen sind. Das ist kein Zufall. Es ist eine ziemlich treffende Beschreibung dessen, wie Maßnahmen zur Verbesserung der Cybersicherheit in den meisten Organisationen tatsächlich ablaufen.

Julian Iavarone, Senior Sales Engineer bei Imperva, a Thales Company, kommentiert: „Wenn es eine Erkenntnis gibt, die Sicherheitsteams aus diesem Bericht mitnehmen sollten, dann diese: Wenn sie das nächste Mal ein Authentifizierungsproblem auf einem Endgerät entdecken, sollten sie nicht einfach nur erleichtert sein, dass sie es entdeckt haben. Vielmehr sollten sie sich fragen, welche Schwachstellen noch daneben lauern könnten. Denn in fast 40 Prozent der von uns untersuchten Fälle gab es noch mehr zu sehen und zu beheben als das anfangs entdeckte Risiko.“

APIs: Wie sind die Systeme aufgebaut?

Die Security-Branche ist mittlerweile recht gut darin geworden, die offensichtlichen Authentifizierungsprobleme zu beheben – jene, die eine Checkliste aufdecken kann, jene, bei denen eine einzige, weit verbreitete Empfehlung bereits eine spürbare Verbesserung bewirken kann. Bei den Problemen, die ein Verständnis dafür erfordern, wie ein System tatsächlich aufgebaut ist, hat sich die Situation jedoch nicht wesentlich verbessert. Genau in diese Kategorie fallen die beiden sich verschärfenden Risiken sowie das Muster, das sie miteinander verbindet. Ein Scanner kann dem Team sagen, dass ein Token mit einem schwachen Algorithmus signiert ist. Weitaus schwieriger ist es, herauszufinden, dass dasselbe Token auch das Geburtsdatum eines Betreibers enthält.

Sicherheitsteams können die Zahl potenzieller Risiken verringern, indem sie die folgenden fünf Tipps beachten:

• Die Minimierung der Token-Nutzdaten sollte zu einer Routineaufgabe werden, nicht zu einem Projekt. Sie sollten prüfen, was in den JWTs enthalten ist und personenbezogene Daten sowie andere sensible Felder, die sie nicht unbedingt benötigen, entfernen. Darüber hinaus sollten sie sogenannte opake Referenz-Token bevorzugen, wenn die benötigten Daten serverseitig nachgeschlagen werden.
• Sie sollten sich speziell mit dem Zugriff über abgelaufene Token beschäftigen. Dabei gilt es sicherzustellen, dass die „exp“- und „nbf“-Claims serverseitig bei jedem Dienst, der Token validiert, durchgesetzt werden und nicht nur am Gateway. Sie sollten die Cache- und Sitzungsungültigkeitslogik auf alles prüfen, was ein Token länger aktiv halten könnte, als es sein sollte.
•  Was funktioniert, sollte weitergeführt werden. Sicherheitsteams müssen die Migration der verbleibenden Basic-Auth-Endpunkte zu OAuth2 oder mTLS abschließen. Sie sollten weiterhin kürzere TTLs mit Refresh-Tokens einführen und sicherstellen, dass die Durchsetzung starker Signaturalgorithmen nicht nur die neuesten, sondern auch Legacy- und Drittanbieter-Dienste abdeckt.
• Audits gilt es nach Endpunkt durchführen, nicht nur nach Risikotyp. Risiken treten wie gezeigt oft gebündelt auf. Deshalb wird ein Endpunkt, der eine Prüfung nicht besteht, wahrscheinlich auch weitere nicht bestehen. Eine umfassende Überprüfung der Authentifizierung bei markierten Endpunkten bringt mehr, als Tickets isoliert nach Risikotyp einzeln abzuarbeiten.
• Die eigenen Zahlen regelmäßig erneut auf den Prüfstand stellen. Benchmarks sind nützlich, um den Kontext zu verstehen, aber der Vergleich, der wirklich hilft, ist der eigene Trend im Zeitverlauf – gemessen auf die gleiche Weise und nach einem regelmäßigen Zeitplan.

Der „Token & Authentication Risk Report 2026“ von Thales API Security basiert auf einem Jahresvergleich, wie Unternehmen mit JWTs, der Basic-Authentifizierung und Token-Lebenszyklen umgehen. Die Grundlage besteht aus Erkennungsdaten aus 1.104 IT-Umgebungen und 32.725 aktiven API-Endpunkten.

Häufige Fragen (FAQ)