Die Sicherheitslücken bei Webanwendungen
Wie fragmentierte Sicherheit zu Risiken führt
Die Geschichte von Unternehmen A und B
Dies ist die Geschichte von Unternehmen A und Unternehmen B, deren auf den ersten Blick unterschiedliche Webanwendungs- und API-Sicherheitsansätze eine gemeinsame unauffällige, aber entscheidende Schwachstelle aufweisen. Diese führte bei beiden Firmen zu Datenschutzverstößen (und allen damit verbundenen negativen Folgen).
Unternehmen A verfügt über den stärksten denkbaren API-Schutz. Es blockiert alle Schemaverstöße, begrenzt die Anfragemenge auf ein vernünftiges Maß und verwendet die neuesten Bedrohungsdaten, um bekanntermaßen bösartige IP-Adressen zu sperren. Die passwortbasierte API-Authentifizierung des Unternehmens könnte noch sicherer sein, wenn sie durch mutual TLS ersetzt würde, doch es gab noch nie einen Sicherheitsvorfall.
Allerdings stammen die API-Sicherheitslösung, der Bedrohungsdaten-Feed und die WAF jeweils von unterschiedlichen Anbietern. Und aufgrund anbieterseitiger Updates sind die für die API-Sicherheit relevanten Bedrohungsdaten nicht mehr mit der WAF kompatibel, die die Kontoanmeldeseite schützt. Deshalb kann ein Angreifer einen neuen SQL-Injection-Exploit auf dieser Seite verwenden und den Benutzernamen und das Passwort eines legitimen Nutzers erlangen. Der Angreifer sendet dann authentifizierte, schemavalidierte Anfragen an die API des Unternehmens und erlangt so zahlreiche vertrauliche Daten.
Was Unternehmen B angeht, so ist dessen Webanwendung vollständig gegen DDoS-Angriffe geschützt. Unternehmen B stellt außerdem eine API für zahlende Nutzer zur Verfügung, die sich eine Möglichkeit zur Integration in die Anwendung von Unternehmen B wünschen.
In diesem Fall erwirbt der Angreifer den API-Schlüssel eines legitimen zahlenden Nutzers im Dark Web. Damit startet er einen langsamen und unauffälligen DDoS-Angriff auf den API-Server von Unternehmen B. Er aktiviert einen Bot, der in unregelmäßigen Abständen Anfragen sendet. Jeder API-Aufruf, den der Bot sendet, wird vom API-Server als legitim angesehen, da er mit einem akzeptablen API-Schlüssel verknüpft ist. Leider hat das Backend-Team von Unternehmen B vergessen, dem eigenen API-Server den genutzten DDoS-Abwehrdienst als Proxy vorzuschalten, auch wenn alle anderen Server der Firma geschützt sind.
Da immer mehr Anfragen auflaufen, ist der API-Server zunehmend überfordert. Irgendwann ist er überhaupt nicht mehr in der Lage, die Anfragen der anderen Nutzer von Unternehmen B noch zu bearbeiten. Viele von ihnen kündigen aus Verärgerung ihre kostenpflichtigen Konten.
Welches Problem haben Unternehmen A und B gemeinsam?
Eine Kombination aus verschiedenen Lösungen führte zu Versäumnissen und Sicherheitslücken
In diesen Beispielen nutzen beide Unternehmen für die Webanwendungs- und API-Sicherheit Lösungen diverser Anbieter. Diese sind nicht miteinander integriert und zu allem Übel auch anfällig für manuelle Fehler.
Um zu verstehen, warum das ein Problem ist, sollten Sie sich die üblichen Elemente eines Sicherheitskonzepts für Webanwendungen und APIs vor Augen führen:
WAF: Blockiert Angriffe auf Webanwendungen und andere Internetpräsenzen
Bot-Management: Überprüft oder blockiert mutmaßlich bösartige Bots
DDoS-Abwehr: Sorgt dafür, dass Internetpräsenzen bei (volumetrischen ebenso wie schwachen und langsamen) DDoS-Angriffen jeglicher Art über das Web erreichbar bleiben
API-Schutz: Umfasst Ratenbegrenzung, Schema-Validierung, Authentifizierung usw. für APIs
Bei Unternehmen A und B sind all diese Schutzmaßnahmen im Einsatz. Weil ihre Sicherheitslösungen für Webanwendungen aber fragmentiert sind (auch wenn sie zu den besten ihres Bereichs gehören), weisen sie Schwachstellen auf, die von Angreifern ausgenutzt werden können.
Bei Unternehmen A mussten sowohl die WAF als auch der API-Schutz, die nicht miteinander integriert, sondern lediglich nebeneinander geschaltet sind, Angriffe jeweils allein abwehren. Angriffe, die von einer Lösung gestoppt werden konnten, waren in der Lage, die anderen zu überwinden. Die DDoS-Abwehr von Unternehmen B hat die API-Infrastruktur nicht geschützt, das Bot-Managementsystem hat keine von Bots stammenden API-Aufrufe erkannt und die Authentifizierung war sowohl schwach als auch leicht angreifbar.
Das sind nur ein paar Beispiele für potenzielle Sicherheitslücken. Andere häufige Lücken in der Sicherheit von Webanwendungen sind:
Begrenzte Bedrohungsdaten: Bedrohungsdaten, die nicht auf dem neuesten Stand sind, nicht an der richtigen Stelle eingehen oder nicht in einem kompatiblen Format vorliegen. Das war bei Unternehmen A zu beobachten.
Zu viele Bedrohungsdaten aus zu vielen Quellen: Dies führt zu Fehlalarmen, Redundanz und anderen Ineffizienzen.
Bot-Fehlalarme: Das kann Nutzer frustrieren, den Dienst verlangsamen und zu einer laxen Durchsetzung der Regeln führen.
Alarm-Müdigkeit: Eine Studie des Ponemon Institute aus dem Jahr 2025 bestätigt, dass das durchschnittliche Unternehmen 45 verschiedene Sicherheitstools einsetzt, was frühere Ergebnisse widerspiegelt, aber immer noch die Verbreitung von Tools und die zunehmende Alarm-Müdigkeit verdeutlicht. Tatsächlich legen neuere Branchenanalysen nahe, dass viele Organisationen jetzt 60–80 verschiedene Sicherheitslösungen verwenden – und einige verwalten bis zu 140 –, was die Komplexität und den Verwaltungsaufwand weiter erhöht.
Unzureichende Authentifizierung: Sowohl Unternehmen A als auch Unternehmen B waren in irgendeiner Form anfällig für den Diebstahl von Zugangsdaten.
Nicht skalierbare Bedrohungsabwehr: Sicherheits-Hardware sorgt für Traffic-Nadelöhre und ist bei großen Angriffen oder bei einer Vielzahl unterschiedlicher Attacken überfordert.
Mit zunehmender Komplexität und Raffinesse von Cyberangriffen werden solche Sicherheitslücken immer riskanter. Laut McKinsey sind die entdeckten Phishing-Websites seit der Einführung von ChatGPT um 138 % gestiegen, was auf die Rolle der generativen KI bei der Erstellung überzeugenderer E-Mails und Deepfakes zurückzuführen ist, die die Fähigkeiten der Angreifer erheblich beschleunigen.
Moderne Angreifer sind oft schneller und bei der Optimierung ihrer Taktik häufig agiler als ihre Ziele.
Das zusätzliche Sicherheitsrisiko von APIs
APIs werden für die Infrastruktur von Webanwendungen moderner Unternehmen immer wichtiger. Heute ist ein erheblicher Teil des von Cloudflare verarbeiteten dynamischen Datenverkehrs API-basiert – und dieser Anteil steigt weiter. Tatsächlich beschreiben sich inzwischen viele Unternehmen als „API first“. Darüber hinaus ist der Anteil des von Cloudflare als bösartig eingestuften und deshalb blockierten Datenverkehrs bei APIs größer als bei Web-Traffic. Das zeigt, dass APIs fest im Fadenkreuz der Angreifer stehen.
Weil APIs oft tief in Webanwendungen eingebettet sind, muss ihre Sicherheit an erster Stelle stehen. Doch wohlmeinende interne Teams stellen APIs häufig schnell bereit – nicht selten ohne Rücksprache mit der IT-Sicherheitsabteilung. Deshalb sind viele Sicherheitsverstöße bei Webanwendungen auf schwachen API-Schutz zurückzuführen.
Ein eindrückliches Beispiel für die wachsenden Risiken im Zusammenhang mit unsicheren APIs kommt von TotalEnergies. Im Jahr 2025 führte eine fehlerhafte API-Infrastruktur zu einem schwindelerregenden 105-fachen Anstieg der exponierten Daten, die von nur 210.715 Datensätzen im Jahr 2024 auf über 22 Millionen anstiegen und auf Dark-Web-Märkten geteilt wurden. Dieser dramatische Sprung unterstreicht die dringende Notwendigkeit, dass der Energiesektor – wie auch alle anderen Branchen – API-Sicherheit als zentrale Infrastruktur behandeln müssen, statt sie nachrangig zu betrachten.
Eine konsolidierte Lösung für die Sicherheit von Webanwendungen
Was wäre, wenn Unternehmen A und B statt eines Flickwerks aus verschiedenen Sicherheitsprodukten alle ihre Sicherheitsservices für Webanwendungen und APIs in einer konsolidierten Plattform gebündelt hätten und diese verschiedenen Dienste alle untereinander integriert wären? Was, wenn zudem Daten über den Zustand der Unternehmensinfrastruktur an einem einzigen Ort angezeigt würden, sodass Angriffe und die Sicherheitslage schnell bewertet werden könnten?
Unternehmen A hätte sicherstellen können, dass alle Elemente seines Sicherheitskonzepts für Webanwendungen und APIs über die neuesten Bedrohungsdaten verfügen und den Angriff stoppen können, noch bevor er überhaupt begonnen hätte – weil alles über eine einzige Plattform abrufbar gewesen wäre. Unternehmen B wiederum hätte seinen DDoS-Schutz leichter auf alle seine Server ausweiten können.
Die Nutzung einer einzigen, übergeordneten Plattform würde eine einfachere und lückenlosere Verwaltung ermöglichen.
Ein solcher konsolidierter Ansatz zur Absicherung von Webanwendungen erfordert eine in hohem Maß skalierbare Infrastruktur, die in der Lage ist, alle Arten von Datenverkehr über einen Proxy an sein Ziel zu leiten. In vergangenen Jahrzehnten haben sich Unternehmen Hardware zugelegt, wenn sie sich gegen neue Angriffe verteidigen oder skalieren mussten. Doch ein cloudbasierter Dienst lässt sich leichter skalieren und sollte in der Lage sein, als Proxy für jede Art von Infrastruktur zu dienen. Und obwohl eine konsolidierte Plattform kein Patentrezept ist, hätte sie den Unternehmen in den hypothetischen Beispielen sicherlich geholfen.
Mehr als eine Gedankenspielerei: Die wachsende Bedeutung von WAAP
Dabei handelt es sich nicht um reine Gedankenspielerei. WAAP-Plattformen (Web Application and API Protection) werden schnell zu einer unverzichtbaren Infrastruktur – nicht nur zu einer theoretischen Best Practice. Der globale Cloud-WAAP-Markt wurde im Jahr 2023 auf 6,12 Mrd. USD geschätzt und soll laut DataHorizzon Research bis 2032 mit einer CAGR von 17,8 % wachsen.
Dieses Wachstum spiegelt den steigenden Bedarf wider, WAF, Bot-Abwehr, DDoS-Schutz und API-Sicherheit in skalierbare Cloud-Dienste zu integrieren – insbesondere, da Webanwendungen und APIs in Multi-Cloud-Umgebungen einer zunehmenden Anzahl komplexer Bedrohungen ausgesetzt sind.
WAAP ist nicht nur ein weiteres Akronym: Die Konsolidierung von WAF, Bot-Management, DDoS-Schutz, API-Sicherheit und anderen Diensten ist für moderne Unternehmen zunehmend von maßgeblicher Bedeutung. Die globale Natur des Internets macht Webanwendungen und APIs für vielfältige – und zunehmend komplexe – Angriffsvektoren anfällig. Es überrascht nicht, dass die Kosten eines Datenverstoßes weiter steigen. Im Jahr 2023 stiegen die durchschnittlichen globalen Kosten für einen Datenverstoß auf 4,45 Mio. USD, wobei US-Organisationen einige der höchsten finanziellen Belastungen tragen – etwa 9,48 Millionen USD pro Vorfall. Anfang 2024 ist diese globale Zahl weiter auf etwa 4,88 Mio. USD angestiegen — ein Anstieg von 10 % innerhalb nur eines Jahres.
Eine weitere Überlegung: heterogene Infrastrukturen
Würden Unternehmen A und B ihre Anwendungen und APIs heute von Grund auf neu entwickeln, könnten sie sie vollständig in der Cloud hosten, zur leichteren Bereitstellung vielleicht sogar bei einem einzigen Hosting-Anbieter. In der Praxis nutzen die meisten Firmen jedoch eine hybride Infrastruktur mit älteren lokalen Datenbankservern, cloudbasierten APIs von Drittanbietern und in mehreren Clouds gehosteten Anwendungsdiensten. Dies bietet viele Vorteile, bringt aber unter dem Sicherheitsaspekt auch eigene Herausforderungen mit sich.
So kann es beispielsweise sein, dass die native Sicherheit im Angebot eines bestimmten Cloud-Providers nicht die gesamte Infrastruktur eines Unternehmens abdeckt. Zunächst einmal kann es sich schon als schwierig erweisen, die gesamte Infrastruktur zu erfassen und abzubilden, um sie dann zu schützen. Last but not least sind die Sicherheitsprodukte des Anbieters möglicherweise nicht mit anderen technischen Lösungen des betreffenden Unternehmens kompatibel.
WAAP muss deshalb nicht nur wichtige Funktionen der Webanwendungssicherheit zusammenführen, sondern auch infrastrukturneutral sein, d. h. die Lösung muss jeder Art von Infrastruktur oder Cloud-Bereitstellungsmodell vorgeschaltet werden können.
Konsolidierte und infrastrukturneutrale Websicherheit
Cloudflare ist Cloud-nativ und infrastrukturneutral, bietet seit mehr als einem Jahrzehnt Webapplikationssicherheit und stellt all diese Funktionen in Gestalt einer konsolidierten Plattform über ein einziges Dashboard bereit. Ein weiterer Vorteil ist, dass wir einen großen Prozentsatz des Internet-Traffics zu Gesicht bekommen, über im Durchschnitt 78 Mio. HTTP-Anfragen pro Sekunde bearbeiten und ~190 Mrd. Cyberbedrohungen pro Tag blockieren. Das erlaubt uns einen einzigartigen Überblick über Zero Day-Bedrohungen und neue Angriffe.
Dieser Beitrag ist Teil einer Serie zu den neuesten Trends und Themen, die für Entscheidungsträger aus der Tech-Branche heute von Bedeutung sind.
Vertiefung des Themas:
2022 wurde Cloudflare von Gartner als ein Marktführer („Leader“) im Gartner® Magic Quadrant™ für Web Application and API Protection (WAAP) eingestuft.
Wichtigste Eckpunkte
Folgende Informationen werden in diesem Artikel vermittelt:
Wie durch eine Vielzahl von Sicherheitslösungen Schwachstellen entstehen können
Beispiele für solche Sicherheitslücken
Weshalb Gartner die Konsolidierung mit einer infrastrukturneutralen Sicherheitsplattform für Webanwendungen empfiehlt