Wer 2026 eine API ins Internet stellt, bekommt früher oder später dieselbe Frage von der Security-Abteilung gestellt: reicht eine Web Application Firewall, oder braucht die Architektur zusätzlich ein API Gateway? Die Antwort ist selten so einfach, wie Vertriebsteams von Cloudflare, AWS oder Kong sie gerne verkaufen. Eine aktuelle Akamai-Studie zeigt, dass 83 Prozent der Unternehmen in Deutschland im vergangenen Jahr einen API-Sicherheitsvorfall erlebt haben, mit einem durchschnittlichen Schaden von rund 470.000 Euro pro Vorfall. Gleichzeitig verlassen sich laut Salt Security noch immer 76 Prozent der CISOs auf klassische WAF- und Gateway-Kontrollen, obwohl diese die häufigsten API-Angriffsmuster oft gar nicht erkennen.
Dieser Vergleich zeigt, wo WAF und API Gateway sich technisch unterscheiden, was beide Produktkategorien 2026 tatsächlich kosten und wann welche Lösung für Unternehmen in Deutschland, Österreich und der Schweiz Sinn ergibt. Wir ziehen dafür aktuelle Preislisten der großen Anbieter heran, die NIST-Richtlinie SP 800-228 zum Schutz von APIs sowie mehrere dokumentierte Datenpannen, bei denen eine klassische WAF den eigentlichen Angriff gar nicht hätte stoppen können.
Was ist eine Web Application Firewall (WAF)?
Eine Web Application Firewall filtert HTTP- und HTTPS-Verkehr, bevor er eine Webanwendung erreicht. Sie prüft Anfragen auf bekannte Angriffsmuster wie SQL-Injection, Cross-Site-Scripting oder einfache Denial-of-Service-Signaturen und blockiert verdächtige Requests anhand von Regelsätzen. Die meisten WAFs arbeiten mit dem OWASP Core Rule Set als Basis und lassen sich um eigene Regeln erweitern. Cloudflare, AWS WAF, Akamai App & API Protector und F5 Distributed Cloud WAF gehören zu den bekanntesten Anbietern, dazu kommen Open-Source-Lösungen wie ModSecurity, die sich etwa vor Nginx schalten lassen. Wer eine solche Open-Source-WAF selbst betreiben will, findet in unserem ModSecurity-3-Setup-Guide eine Schritt-für-Schritt-Anleitung.
Der große Vorteil einer WAF liegt in der Einfachheit der Integration. Sie sitzt vor der Anwendung, braucht keinen Code-Zugriff und lässt sich meist in Stunden aktivieren. Der Nachteil zeigt sich bei APIs: Eine WAF versteht selten die Geschäftslogik hinter einem Endpunkt. Sie erkennt eine SQL-Injection im Body, aber nicht, ob ein authentifizierter Nutzer gerade auf fremde Kundendaten zugreift, weil eine ID in der URL nicht gegen seine Berechtigung geprüft wird. Palo Alto Networks beschreibt diese Rolle in seiner Cyberpedia-Übersicht als reinen Perimeterschutz auf Payload-Ebene, nicht als Kontrolle für Geschäftslogik oder Nutzerrechte.
In der Praxis unterscheiden sich WAF-Produkte zudem stark in der Betriebsart. Edge-Anbieter wie Cloudflare oder Akamai laufen als globales Netzwerk vor der eigentlichen Infrastruktur und bündeln WAF-Regeln mit DDoS-Schutz und Bot-Management in einem Dashboard. Cloud-native WAFs wie AWS WAF oder Azure Web Application Firewall sitzen dagegen direkt an einem Load Balancer oder Content Delivery Network innerhalb der jeweiligen Cloud-Umgebung und lassen sich per Infrastructure-as-Code mit dem restlichen Deployment versionieren. Selbst gehostete Varianten wie ModSecurity oder Coraza bieten die größte Kontrolle, verlangen im Gegenzug aber eigenes Patch-Management und eigene Regelpflege.
Was ist ein API Gateway?
Ein API Gateway ist die zentrale Eingangstür für API-Aufrufe. Es übernimmt Routing an Backend-Dienste, Authentifizierung, Rate Limiting, Protokollübersetzung und oft auch Schema-Validierung gegen eine OpenAPI-Spezifikation. Verbreitete Produkte sind AWS API Gateway, Azure API Management, Kong Gateway und Apache APISIX. Anders als eine WAF kennt ein Gateway die Struktur der API: welche Felder ein Endpunkt erwartet, welche Rollen einen Aufruf ausführen dürfen und wie viele Anfragen ein Client pro Minute senden darf.
Diese Kenntnis der API-Struktur macht ein Gateway zum besseren Werkzeug gegen Autorisierungsfehler wie Broken Object Level Authorization, kurz BOLA. Gleichzeitig ersetzt ein Gateway keine WAF vollständig, denn die meisten Implementierungen prüfen Payloads nicht auf klassische Injection-Muster, sofern kein zusätzliches Sicherheitsmodul aktiv ist. Kong Gateway etwa ist in der Open-Source-Variante kostenlos, deckt aber ohne Plugins weder Bot-Erkennung noch tiefe Payload-Analyse ab.
In Kubernetes-Umgebungen verschwimmt die Grenze zwischen Gateway und Ingress-Controller zusätzlich. Viele Teams nutzen ohnehin einen Ingress-Controller für das Routing zwischen Services und erweitern ihn um API-Gateway-Funktionen, statt eine separate Komponente zu betreiben. Grundlagen zum Aufbau eines solchen Reverse Proxys mit sauberer TLS-Terminierung erklärt unser Nginx-Reverse-Proxy-Guide. Wer WAF- und Gateway-Funktion in einer einzigen Ingress-Komponente bündelt, muss deren Patch-Stand konsequent pflegen, denn ein Ausfall oder eine Schwachstelle in dieser einen Komponente betrifft dann Lastverteilung, WAF-Filterung und API-Routing gleichzeitig.
WAF vs. API Gateway: Die technischen Unterschiede im Überblick
Die folgende Tabelle fasst die wichtigsten Unterschiede zwischen einer klassischen WAF und einem API Gateway zusammen, basierend auf den Herstellerdokumentationen von AWS, Cloudflare, Kong und der NIST-Richtlinie SP 800-228.
| Kriterium | Web Application Firewall | API Gateway |
|---|---|---|
| Primäre Funktion | Payload-Filterung gegen bekannte Angriffsmuster | Routing, Auth, Rate Limiting, Schema-Prüfung |
| Schutzebene | Anwendungsschicht (Layer 7), request-zentriert | Anwendungsschicht (Layer 7), API-zentriert |
| Regelmodell | Meist negativ (Blacklist bekannter Muster) | Meist positiv (nur erlaubte Schemas/Routen) |
| Authentifizierung | Kaum vorhanden, allenfalls IP- oder Token-Checks | OAuth2, JWT, API-Keys, mTLS als Kernfunktion |
| Rate Limiting | Grob, meist global oder pro IP | Granular, pro Client, Route oder Nutzer |
| Schema-Validierung | Nicht vorgesehen | Ja, gegen OpenAPI/Swagger möglich |
| Erkennung von BOLA/IDOR | Sehr eingeschränkt | Möglich mit Autorisierungs-Policies |
| Bot-Management | Oft integriert (z. B. Cloudflare, Akamai) | Selten nativ, meist über Zusatzmodule |
| DDoS-Schutz | Häufig inklusive, besonders bei Edge-Anbietern | Begrenzt, meist nur Rate Limiting |
| Protokolle | HTTP/HTTPS, teils WebSocket | REST, GraphQL, gRPC, WebSocket |
| Typischer Standort | Edge oder Load Balancer | Vor Microservices oder Backend-Diensten |
| Beispielprodukte | Cloudflare WAF, AWS WAF, Akamai, ModSecurity | AWS API Gateway, Azure APIM, Kong, APISIX |
Der Kern des Unterschieds: Eine WAF fragt, ob eine Anfrage bösartig aussieht. Ein API Gateway fragt, ob dieser Client diese Route mit diesen Daten überhaupt aufrufen darf. Beide Fragen sind wichtig, aber keine ersetzt die andere vollständig.
Ein Begriff, der in Herstellermaterial 2026 zunehmend auftaucht, ist WAAP, kurz für Web Application and API Protection. Anbieter wie Akamai, Cloudflare und F5 bündeln darunter WAF, Bot-Management, DDoS-Schutz und teils auch API-Discovery in einem einzigen Produkt. Das löst das Problem der doppelten Zuständigkeit teilweise, ersetzt aber ein dediziertes API Gateway mit granularer Autorisierung pro Route in der Regel nicht vollständig. Wer sich für WAAP statt getrennter Produkte entscheidet, sollte in den Vertragsunterlagen genau prüfen, wie tief die API-spezifischen Kontrollen tatsächlich reichen, und nicht nur auf den Marketingbegriff vertrauen.
Wie eine WAF technisch funktioniert
Negativ- vs. Positiv-Modell
Die meisten kommerziellen WAFs arbeiten primär mit einem Negativ-Modell: Sie definieren, was verboten ist, und lassen alles andere durch. Das OWASP Core Rule Set enthält hunderte Signaturen für SQL-Injection, XSS, Command Injection und Pfad-Traversal. Neuere WAFs wie Cloudflare oder Akamai App & API Protector ergänzen das um maschinelles Lernen, das Anomalien im Traffic-Muster erkennt, etwa ungewöhnlich viele Requests von derselben Session in kurzer Zeit.
Ein reines Positiv-Modell, bei dem nur explizit erlaubte Muster durchgelassen werden, ist bei generischen Webanwendungen selten praktikabel, weil sich Formulare und Parameter ständig ändern. Bei APIs mit fester Schema-Definition ist ein Positiv-Modell dagegen deutlich realistischer. Das ist einer der Gründe, warum API Gateways hier oft die robustere Wahl sind.
Wie ein API Gateway technisch funktioniert
Ein API Gateway terminiert eingehende Verbindungen, prüft Authentifizierungs-Header, validiert den Request gegen ein hinterlegtes Schema und leitet den Aufruf erst dann an den passenden Backend-Dienst weiter. Kong Gateway etwa nutzt dafür ein Plugin-System: Auth-Plugins prüfen JWTs oder API-Keys, Rate-Limiting-Plugins zählen Aufrufe pro Consumer, und Transformation-Plugins passen Header oder Body an, bevor die Anfrage das Backend erreicht.
Eine einfache Rate-Limiting-Konfiguration in Kong sieht in der Praxis so aus:
plugins:
- name: rate-limiting
config:
minute: 100
policy: local
- name: jwt
config:
claims_to_verify:
- expDiese wenigen Zeilen begrenzen Aufrufe auf 100 pro Minute und Client und verlangen ein gültiges, nicht abgelaufenes JWT-Token. Eine klassische WAF kann so etwas nicht abbilden, weil ihr das Konzept eines Consumers mit individuellem Kontingent fehlt.
Moderne Gateways unterscheiden sich zudem stark darin, welche API-Stile sie nativ unterstützen. Für klassische REST-APIs mit JSON-Payloads bieten praktisch alle Produkte Schema-Validierung an. Bei GraphQL wird es komplexer, weil ein einzelner Endpunkt beliebig verschachtelte Queries zulässt und ein Angreifer über tief verschachtelte Abfragen gezielt hohe Serverlast erzeugen kann, ein Muster, das eine klassische WAF praktisch nie erkennt. Kong, Azure API Management und AWS API Gateway bieten dafür inzwischen Query-Komplexitäts-Limits an, die die Verschachtelungstiefe und Feldanzahl pro Anfrage begrenzen. Bei gRPC-Diensten wiederum punkten Gateways, die HTTP/2 nativ terminieren, während viele ältere WAF-Implementierungen an dieser Stelle noch auf HTTP/1.1 zurückfallen und den binären Protokollrahmen gar nicht sinnvoll inspizieren können.
Benchmarks: Latenz, Erkennungsraten und Fehlalarme im Vergleich
NIST SP 800-228: Latenz durch doppeltes Parsing
Die US-Standardbehörde NIST hat ihre Richtlinie SP 800-228 zum Schutz von APIs in Cloud-nativen Systemen im Juni 2025 final veröffentlicht und im März 2026 aktualisiert. Sie beschreibt ein konkretes Latenzproblem: Wenn eine WAF und ein API Gateway getrennt betrieben werden, parst jede Komponente denselben Request erneut, was Rechenzeit kostet und Antwortzeiten verlängert. NIST-Forscher Ramaswamy Chandramouli fasst die Grenzen einer isolierten WAF so zusammen: “WAFs generally do not work at the API level” (Ramaswamy Chandramouli, NIST). An anderer Stelle des Dokuments präzisiert er die Grenze der Payload-Prüfung: “A WAF can scan a request for a payload that looks like a SQL injection attack, but it cannot assert, for example, that a request has a ‘name’ field that is a string less than 100 characters long” (Ramaswamy Chandramouli, NIST).
Als Lösung empfiehlt NIST entweder eine hybride WAF-Bereitstellung, bei der nur ein Minimum an Regeln nahe der Anwendung läuft, oder die direkte Integration der WAF-Funktion in das API Gateway selbst, um doppeltes Parsen zu vermeiden. Die grundsätzliche Rolle einer WAF beschreibt der Bericht so: “WAFs mitigate risks related to a request’s metadata and payload without needing the application to be involved” (Ramaswamy Chandramouli, NIST).
Salt Security und Akamai: Vertrauen trotz Erkennungslücken
Der State of API Security Report 2025 von Salt Security zeigt eine Kluft zwischen Vertrauen und Wirkung: 76 Prozent der befragten CISOs verlassen sich weiterhin primär auf WAFs und Gateways für ihre API-Sicherheit. Gleichzeitig entstehen die größten Schäden laut Salt Security durch Angriffe auf Geschäftslogik und Autorisierung, also genau die Kategorie, die klassische Signaturen nicht erfassen. Die Akamai-Studie zur EMEA-Region 2026 liefert dazu die deutsche Zahl: 83 Prozent der Unternehmen hatten im vergangenen Jahr einen API-Sicherheitsvorfall, mit durchschnittlich 540.041 US-Dollar beziehungsweise rund 470.000 Euro Schaden pro Fall. Drei unabhängige Quellen, NIST, Salt Security und Akamai, kommen damit zum selben Schluss: Eine WAF allein reicht bei API-Verkehr nicht aus.
Standardisierte, herstellerunabhängige Latenz- oder Fehlalarm-Benchmarks für den direkten Vergleich von WAF und API Gateway existieren bislang nicht in einer Form, die sich seriös in einer einzelnen Kennzahl zusammenfassen ließe. Analysten wie Gartner bewerten API-Management-Plattformen in ihrem jährlichen Magic Quadrant primär qualitativ, über Kundenzufriedenheit, Funktionsumfang und Marktpräsenz, nicht über standardisierte Durchsatz- oder Latenztests. Das ist einer der Gründe, warum sich Unternehmen bei der Produktwahl stärker auf dokumentierte Referenzarchitekturen wie die von Microsoft oder Honor und auf eigene Lasttests verlassen sollten als auf einzelne Marketingzahlen der Hersteller.
Preisvergleich 2026: Was WAF und API Gateway wirklich kosten
Die Preismodelle unterscheiden sich stark. WAFs werden meist pro Domain oder pro Regel abgerechnet, API Gateways meist pro Million Aufrufe. Die folgende Übersicht zeigt die aktuellen, öffentlich einsehbaren Listenpreise, Stand August 2026. Alle US-Dollar-Preise stammen direkt aus den Preislisten der Hersteller, die meist keine separaten Euro-Tarife veröffentlichen, Unternehmen in Deutschland sollten daher zusätzlich Wechselkursschwankungen und die in vielen Verträgen übliche jährliche statt monatliche Abrechnung einplanen.
| Produkt | Einstiegspreis | Abrechnungsmodell |
|---|---|---|
| Cloudflare WAF (Pro) | 20 $/Monat pro Domain (jährlich) | Flatrate pro Zone |
| Cloudflare WAF (Business) | 200 $/Monat pro Domain (jährlich) | Flatrate pro Zone |
| AWS WAF | 5 $ pro Web ACL + 1 $ pro Regel/Monat | 0,60 $ pro Mio. geprüfter Requests |
| AWS API Gateway (REST) | 3,50 $ pro Mio. Aufrufe (erste 333 Mio.) | Gestaffelt nach Volumen |
| AWS API Gateway (HTTP API) | 1,00 $ pro Mio. Aufrufe (erste 300 Mio.) | Gestaffelt nach Volumen |
| Azure API Management (Consumption) | 1 Mio. Aufrufe/Monat gratis, danach ca. 3,50 $/Mio. | Pay-per-Call |
| Azure API Management (Standard) | ca. 700–730 $/Monat pro Einheit | Fixpreis pro Unit |
| Kong Gateway (Open Source) | 0 € (Apache-2.0-Lizenz) | Selbst gehostet |
| Kong Konnect Plus | ca. 105 $/Monat pro Gateway-Service | 1 Mio. Requests inklusive, danach ca. 34,25 $/Mio. |
| Akamai App & API Protector | Nur auf Anfrage, Praxisbeispiele ab ca. 6.000 $/Monat | Traffic- und feature-basiert |
Auffällig: Kong Gateway ist als Open-Source-Variante kostenlos, deckt dann aber keine WAF-Funktionen ab. AWS trennt WAF und Gateway strikt in zwei Rechnungsposten, was bei hohem Traffic schnell zu spürbaren Zusatzkosten führt, wie die offizielle AWS-WAF-Preisliste und die AWS-API-Gateway-Preisliste zeigen. Enterprise-WAAP-Lösungen wie Akamai oder F5 Distributed Cloud WAF veröffentlichen keine Listenpreise. Branchenschätzungen und öffentlich einsehbare Partnerangebote bewegen sich zwischen 50.000 und 500.000 Dollar pro Jahr, je nach Traffic-Volumen und Funktionsumfang.
Wichtig für die Kalkulation ist die Gesamtbetriebskosten-Perspektive, nicht nur der Listenpreis. Azure staffelt seine API-Management-Tarife von der kostenlosen Consumption-Stufe bis zur Premium-Stufe für rund 2.700 bis 3.000 Dollar im Monat, die dafür Multi-Region-Support und ein 99,99-Prozent-SLA mitbringt. Bei Cloudflare zahlen Unternehmen dagegen pro Domain, was bei vielen Subdomains oder Mandanten schnell zu einer zweistelligen Zahl an Einzelverträgen führen kann. Wer mehrere Produkte kombiniert, etwa Cloudflare am Edge plus Kong Gateway im Cluster, sollte deshalb nicht nur die Grundgebühr vergleichen, sondern auch, wie die Kosten mit steigendem Traffic skalieren. Bei AWS API Gateway etwa sinkt der Preis pro Million Aufrufe automatisch mit dem Volumen, bei Azure Premium-Einheiten dagegen bleibt der Fixpreis pro Einheit gleich, unabhängig davon, wie viel tatsächlich durchgereicht wird.
Praxisbeispiele: Wenn eine WAF allein nicht reicht
Theorie und Herstellerdokumentation sind das eine, dokumentierte Vorfälle das andere. Die folgenden fünf Beispiele stammen aus öffentlich zugänglichen Untersuchungsberichten, Unternehmensmitteilungen und Ingenieurs-Blogs und zeigen sowohl, wo eine reine WAF an ihre Grenzen stößt, als auch, wie kombinierte Architekturen in der Praxis konkret aussehen.
Drei Datenpannen mit Autorisierungsfehlern
Bei T-Mobile begann ein Angreifer laut Unternehmensangaben um den 25. November 2022 eine einzelne API zu missbrauchen, die Kundendaten ohne ausreichende Berechtigungsprüfung auslieferte. Erst am 5. Januar 2023 wurde der Zugriff entdeckt, ein Tag später gestoppt. Betroffen waren rund 37 Millionen Konten mit Namen, Adressen, Telefonnummern und Geburtsdaten. Die Rekonstruktion in der Fachöffentlichkeit deutet auf eine klassische Broken Object Level Authorization hin: Die API prüfte nicht, ob die anfragende Person tatsächlich Zugriff auf die abgefragte Kunden-ID haben durfte.
Beim australischen Telekomanbieter Optus führte im September 2022 ein unauthentifizierter API-Endpunkt zum Abfluss von Daten aus rund 9,8 Millionen Kundenkonten, bei etwa 2,4 bis 2,8 Millionen davon inklusive Ausweisnummern. Die API war direkt mit der Kundendatenbank verbunden und verlangte keine Authentifizierung. Eine WAF hätte diesen Verkehr vermutlich als normalen GET-Request durchgelassen, weil syntaktisch nichts Verdächtiges an den Anfragen war.
Beim Fitness-Anbieter Peloton entdeckte der Sicherheitsforscher Jan Masters 2021, dass die API auch für als privat markierte Profile Alter, Standort, Gewicht und Trainingsdaten auslieferte. Die Anfragen sahen für eine WAF völlig normal aus. Das Problem lag in der fehlenden Durchsetzung der Privatsphäre-Einstellungen auf API-Ebene, nicht im Payload selbst.
Zwei Beispiele für kombinierte Architekturen
Microsoft beschreibt in einer Referenzarchitektur vom 17. Juli 2025 ein Muster, bei dem eingehender Verkehr zunächst durch Azure Application Gateway im WAF-Modus mit OWASP Core Rule Set 3.2 läuft und danach an Azure API Management weitergereicht wird, das Authentifizierung, Rate Limiting und Routing zu Backend-Diensten wie AKS übernimmt. Ein Folgeartikel im Azure-Networking-Blog vom 18. November 2025 ergänzt eine Produktions-Checkliste, unter anderem den Wechsel von Detection- zu Prevention-Modus und gezielte Ausnahmen für JSON-Payloads, um Fehlalarme zu reduzieren.
Der Elektronikhersteller Honor beschreibt in einem Fallbeispiel des API-Gateway-Anbieters API7.ai vom 23. Mai 2025, wie eine klassische Inline-WAF zum Single Point of Failure wurde: Fiel die WAF aus, stand der gesamte Verkehr still. Die Lösung war eine Bypass-Architektur mit dem API Gateway APISIX als primärem Eingangspunkt, das nur ausgewählten Verkehr zur WAF-Prüfung weiterleitet und bei einem WAF-Ausfall direkt an die Backends durchreicht. Laut Fallbeispiel verarbeitet die APISIX-Schicht dabei mehrere Millionen Anfragen pro Sekunde.
Die fünf Beispiele zusammen zeichnen ein klares Bild. Bei den drei Datenpannen fehlte nicht in erster Linie eine WAF-Regel, sondern eine Autorisierungsprüfung auf API-Ebene, die technisch korrekte, aber unberechtigte Anfragen erkannt hätte. Bei den beiden Architektur-Beispielen von Microsoft und Honor zeigt sich umgekehrt, dass eine gut geplante Kombination aus WAF und Gateway nicht nur die Erkennungsrate verbessert, sondern auch die Verfügbarkeit erhöht, weil ein Ausfall einer Komponente nicht zwangsläufig den gesamten Traffic lahmlegt.
Die Grenzen der WAF bei modernen API-Angriffen
Der OWASP API Security Top 10 listet Broken Object Level Authorization seit Jahren auf Platz eins der häufigsten API-Schwachstellen, gefolgt von fehlerhafter Authentifizierung und übermäßiger Datenexposition. Keine dieser drei Kategorien lässt sich mit klassischen WAF-Signaturen zuverlässig erkennen, weil die Anfragen selbst technisch korrekt formatiert sind. Der Unterschied zwischen einem legitimen und einem böswilligen Aufruf liegt in der Berechtigung, nicht im Payload. Genau dieses Muster zog sich durch alle drei Datenpannen aus dem vorherigen Abschnitt: Weder bei T-Mobile noch bei Optus noch bei Peloton hätte eine noch so gut gepflegte WAF-Regel den eigentlichen Fehler erkannt, weil keiner der Requests wie ein klassischer Angriff aussah.
Gerade deshalb betont die NIST-Richtlinie SP 800-228A, deren erster öffentlicher Entwurf am 18. Mai 2026 erschien, robuste Autorisierung, unerratbare Ressourcen-IDs und Rate Limiting als primäre Schutzmaßnahmen für REST-APIs, nicht die WAF-Signatur. Das bedeutet nicht, dass eine WAF überflüssig wird. Sie bleibt die erste Verteidigungslinie gegen automatisierte Massenangriffe, einfache Injection-Versuche und volumetrische Attacken. Aber sie ist eben nur eine von mehreren Schichten, keine Komplettlösung für API-Sicherheit.
OWASP API Security Top 10: Wo eine WAF systematisch blind bleibt
Der OWASP API Security Top 10 unterscheidet sich bewusst von der klassischen OWASP Top 10 für Webanwendungen. Während die generische Liste stark auf Injection und XSS fokussiert ist, dominieren bei APIs Autorisierungs- und Design-Probleme: Broken Object Level Authorization auf Platz eins, gefolgt von Broken Authentication und Broken Object Property Level Authorization, das übermäßige Datenexposition und unsichere Massenzuweisung von Feldern zusammenfasst. Erst danach folgen Themen wie unbeschränkter Ressourcenverbrauch und fehlerhafte Autorisierung auf Funktionsebene.
Diese Reihenfolge ist kein Zufall, sondern spiegelt Auswertungen realer Vorfälle wider. Der API-Sicherheitsanbieter Cequence beschreibt in einer Analyse zum Zusammenspiel von WAF und API Gateway, dass beide Komponenten zusammen zwar Grundschutz liefern, für die oberen Plätze der OWASP-API-Liste aber zusätzliche, API-spezifische Kontrollen wie Verhaltensanalyse und Schema-Governance nötig sind. Für Teams, die ihre eigenen APIs gegen genau diese Kategorie testen wollen, bieten sich dieselben Werkzeuge an, die auch klassische Pentests nutzen. Ein Vergleich der gängigen Optionen findet sich in unserem Beitrag Burp Suite vs. OWASP ZAP, beide Tools lassen sich gezielt auf API-Endpunkte statt auf klassische Formulare ansetzen.
Welche Lösung passt zu welchem Szenario? Sechs Praxisempfehlungen
Nicht jedes Unternehmen braucht denselben Sicherheitsstapel. Die folgenden sechs Szenarien orientieren sich an typischen Architekturen, wie sie in den vorangegangenen Praxisbeispielen und Preisvergleichen bereits sichtbar wurden, und geben eine konkrete Startempfehlung für jeden Fall.
- Reine Marketing-Website ohne eigene API: Eine WAF wie Cloudflare Pro reicht aus, ein API Gateway wäre hier reiner Overhead.
- Mobile-App-Backend mit Nutzerkonten: Ein API Gateway mit OAuth2 und granularem Rate Limiting ist Pflicht, eine WAF davor ist sinnvolle Ergänzung gegen automatisierte Angriffe.
- E-Commerce mit Zahlungs-APIs: Kombination aus WAF und Gateway, da sowohl PCI-DSS-Anforderungen an Payload-Filterung als auch strikte Autorisierung pro Bestellung nötig sind.
- Microservices auf Kubernetes: Ein API Gateway wie Kong oder APISIX im Cluster, ergänzt um eine WAF am Edge, etwa über Cloudflare oder eine Ingress-Erweiterung wie ModSecurity.
- Unternehmen unter NIS2-Pflicht in Deutschland: Kombinierte Lösung nahezu unvermeidbar, da Aufsichtsbehörden inzwischen sowohl Perimeterschutz als auch nachweisbare Zugriffskontrolle auf API-Ebene erwarten.
- Öffentliche Partner- oder Open-APIs: Schwerpunkt auf dem Gateway, mit Schema-Validierung, Versionierung und Kontingenten pro Partner, WAF als zusätzliche Sicherheitsschicht gegen Missbrauch.
Wer betreibt was? WAF und Gateway im Unternehmen richtig zuordnen
In vielen Unternehmen sorgt allein die Frage nach der Zuständigkeit für Reibung. Eine WAF wird traditionell vom zentralen Security- oder Netzwerkteam betrieben, oft als Teil der Perimeter-Infrastruktur, ähnlich wie Firewalls oder Intrusion-Detection-Systeme. Ein API Gateway dagegen liegt in den meisten Organisationen näher am Plattform- oder Entwicklungsteam, weil es eng mit dem Deployment einzelner Services verzahnt ist und sich Routing-Regeln oft parallel zu neuen Features ändern.
Diese organisatorische Trennung ist einer der unterschätzten Gründe, warum WAF und Gateway in der Praxis selten optimal aufeinander abgestimmt sind. Wenn das Security-Team WAF-Regeln unabhängig vom Plattform-Team pflegt, entstehen genau die Doppelprüfungen und blinden Flecken, vor denen NIST warnt. Erfolgreiche Migrationen, wie im Microsoft-Beispiel beschrieben, setzen deshalb auf ein gemeinsames Regelwerk und einen abgestimmten Freigabeprozess zwischen beiden Teams, statt getrennte Silos mit eigenen Änderungszyklen zu betreiben. Für kleinere Unternehmen ohne getrennte Teams lohnt sich der Blick auf Produkte wie Cloudflare oder Kong Konnect, die WAF- und Gateway-Konfiguration zumindest in einer gemeinsamen Oberfläche zusammenführen.
Migrationsleitfaden: Von reiner WAF zur kombinierten Architektur
Unternehmen, die aktuell nur eine WAF betreiben und auf ein kombiniertes Modell umstellen wollen, sollten das schrittweise angehen, um Ausfälle zu vermeiden. Der folgende Ablauf orientiert sich an den Empfehlungen aus der NIST-Richtlinie SP 800-228 und der Praxis-Checkliste von Microsoft. Er eignet sich sowohl für Teams, die von einer reinen WAF-Lösung kommen, als auch für Teams, die umgekehrt bereits ein API Gateway betreiben und nun gezielt eine WAF-Schicht ergänzen wollen, etwa nachdem ein Penetrationstest mit Werkzeugen wie Burp Suite oder OWASP ZAP fehlende Payload-Filterung aufgedeckt hat.
- API-Inventar erstellen: Alle aktiven Endpunkte erfassen, inklusive Schatten-APIs, die nicht in der offiziellen Dokumentation stehen.
- Bestehende WAF-Regeln auf False-Positive-Rate gegen echten API-Traffic prüfen, bevor neue Komponenten hinzukommen.
- Gateway im Parallelbetrieb aufsetzen, zunächst nur mit Logging, ohne aktive Blockierung.
- Authentifizierung und Rate Limiting im Gateway konfigurieren und gegen Testverkehr validieren.
- Schema-Validierung aktivieren, ausgehend von der bestehenden OpenAPI-Spezifikation.
- WAF-Regeln auf die reduzierte Rolle als Payload-Filter zuschneiden, um doppeltes Parsen zu vermeiden.
- Gateway schrittweise von Logging- in Blocking-Modus versetzen, beginnend mit unkritischen Routen.
- Monitoring und Alerting für beide Schichten zusammenführen, idealerweise in einem gemeinsamen SIEM.
- Lasttest unter realistischem Traffic, um die zusätzliche Latenz durch zwei Prüfschichten zu messen.
- Vollständige Umstellung auf Blocking-Modus, mit Rollback-Plan für die ersten Wochen im Live-Betrieb.
Wichtig ist Schritt sechs: Wer WAF und Gateway einfach nebeneinander stehen lässt, ohne die Regeln aufeinander abzustimmen, produziert genau das doppelte Parsing, vor dem NIST warnt. Bei Azure lässt sich das reduzieren, indem Application Gateway nur grobe Filterung übernimmt und die feingranulare Prüfung komplett bei API Management liegt.
Ein häufiger Fehler in der Praxis ist, Schritt neun zu überspringen und direkt in den produktiven Blocking-Modus zu wechseln. Gerade bei APIs mit ungewöhnlichen, aber legitimen Payloads, etwa Datei-Uploads oder verschachtelten JSON-Strukturen, führt das schnell zu falsch positiven Blockierungen und genervten Kunden. Ein Testlauf von mindestens ein bis zwei Wochen im reinen Log-Modus, bevor eine neue Regel oder ein neues Gateway scharf geschaltet wird, hat sich in den dokumentierten Microsoft- und Kong-Referenzarchitekturen als Standardvorgehen etabliert.
Vor- und Nachteile im direkten Vergleich
Bevor eine Kaufentscheidung fällt, lohnt sich der nüchterne Blick auf die jeweiligen Stärken und Schwächen beider Produktkategorien. Die folgende Übersicht fasst zusammen, was in den vorherigen Abschnitten anhand von Preisen, Benchmarks und Praxisbeispielen bereits sichtbar wurde.
WAF: Vorteile
- Schnelle Integration ohne Änderungen am Anwendungscode
- Guter Schutz gegen automatisierte Massenangriffe und bekannte Injection-Muster
- Bei Edge-Anbietern oft inklusive DDoS- und Bot-Schutz
WAF: Nachteile
- Erkennt Autorisierungsfehler wie BOLA praktisch nicht
- Regelpflege kann bei individuellen APIs zu vielen Fehlalarmen führen
- Kein Verständnis für API-Schemas oder Geschäftslogik
API Gateway: Vorteile
- Granulare Authentifizierung, Autorisierung und Rate Limiting pro Client
- Schema-Validierung reduziert die Angriffsfläche strukturell
- Open-Source-Optionen wie Kong OSS sind kostenlos nutzbar
API Gateway: Nachteile
- Ohne Zusatzmodule kein tiefer Payload-Scan gegen Injection
- Höherer Konfigurationsaufwand als eine Standard-WAF
- Enterprise-Tarife wie Kong Konnect oder Azure Premium sind kostspielig
Deutschland und die NIS2-Pflicht: Warum die Kombination jetzt drängt
Seit dem 6. Dezember 2025 gilt für rund 29.500 Unternehmen in Deutschland eine Multi-Faktor-Authentifizierungspflicht im Rahmen der NIS2-Umsetzung, verbunden mit Bußgeldern in zweistelliger Millionenhöhe bei Verstößen. Eine aktuelle eco-Umfrage aus Deutschland zeigt außerdem, wie sich das Verhalten der Endnutzer verschiebt: 39 Prozent aktivieren Zwei-Faktor-Authentifizierung, wo immer möglich, 32 Prozent nutzen bereits Passkeys oder biometrische Anmeldung, 24 Prozent verlassen sich auf Passwort-Manager. Für Unternehmen bedeutet das doppelten Druck: Endnutzer erwarten moderne Authentifizierung, während Aufsichtsbehörden nachweisbare technische Kontrollen auf allen Ebenen verlangen, inklusive der API-Schicht.
Das BSI verweist in seinen Empfehlungen für Unternehmen wiederholt auf mehrschichtige Schutzkonzepte statt Einzellösungen. Eine WAF allein deckt diese Anforderung nicht ab, weil sie keine granulare Zugriffskontrolle auf Objektebene bietet, wie sie etwa bei Kundendaten-APIs nötig ist. Für DACH-Unternehmen mit NIS2-Pflicht führt an einer Kombination aus WAF und API Gateway inzwischen kaum ein Weg vorbei, allein schon aus Dokumentationsgründen gegenüber Prüfern.
In Österreich und der Schweiz ist die Rechtslage etwas anders gelagert, da NIS2 als EU-Richtlinie in der Schweiz nicht direkt greift und Österreich die Umsetzung ebenfalls über ein eigenes Gesetz regelt. Trotzdem orientieren sich viele Konzerne in beiden Ländern an denselben technischen Standards, weil sie ohnehin mit deutschen oder EU-weiten Tochtergesellschaften verflochten sind. Für Sicherheitsteams in der gesamten DACH-Region lohnt sich deshalb, die Kombination aus WAF und API Gateway nicht als deutsche Compliance-Pflicht, sondern als Mindeststandard für jede API mit personenbezogenen Daten zu betrachten, unabhängig vom konkreten Gesetzestext.
Häufige Fehler bei der Kombination von WAF und API Gateway
Der häufigste Fehler ist, beide Komponenten unabhängig voneinander zu betreiben und im Ernstfall nicht zu wissen, welche Schicht eine bestimmte Anfrage überhaupt geprüft hat. Ohne zusammengeführtes Logging lässt sich ein Vorfall kaum rekonstruieren, weil die WAF nur die grobe HTTP-Ebene sieht, während das Gateway den Kontext von Nutzer, Route und Berechtigung kennt. Ein gemeinsames SIEM oder zumindest korrelierte Log-IDs zwischen beiden Systemen sind deshalb keine Kür, sondern Voraussetzung für belastbare Forensik.
Der zweite häufige Fehler ist eine zu aggressive WAF-Konfiguration direkt vor dem Gateway, die legitime API-Aufrufe blockiert, weil generische Regeln nicht auf das tatsächliche Schema abgestimmt sind. Große verschachtelte JSON-Bodies, Binärdaten in Base64 oder GraphQL-Queries mit vielen verschachtelten Feldern lösen bei Standard-Regelsätzen oft Fehlalarme aus. NIST empfiehlt deshalb explizit, WAF-Ausnahmen gezielt für bekannte, legitime API-Payload-Strukturen zu definieren, statt Regeln pauschal zu lockern und damit den eigentlichen Schutz zu schwächen.
Der dritte Fehler betrifft die Reihenfolge im Migrationsprozess: Teams, die zuerst das Gateway in den vollen Blocking-Modus schalten und die WAF-Anpassung aufschieben, riskieren doppelte Wartungsfenster und widersprüchliche Fehlermeldungen für Kunden. Der in diesem Artikel beschriebene, schrittweise Ablauf mit paralleler Logging-Phase reduziert dieses Risiko deutlich, verlangt im Gegenzug aber mehr Geduld, als viele Projektpläne einkalkulieren.
Ein vierter, seltener diskutierter Fehler ist das Fehlen eines klaren Eskalationswegs, wenn WAF und Gateway sich in ihrer Entscheidung widersprechen, etwa wenn das Gateway einen Nutzer als berechtigt einstuft, die WAF den Request aber wegen eines ungewöhnlichen Musters blockiert. Ohne definierte Priorität zwischen beiden Systemen entscheidet im Zweifel der Zufall der Konfigurationsreihenfolge darüber, ob ein Kunde eine Fehlermeldung sieht oder nicht. Ein dokumentiertes Regelwerk, welche Schicht im Konfliktfall Vorrang hat, gehört deshalb in jede produktive Kombination aus WAF und API Gateway.
Das Urteil: WAF vs. API Gateway im Jahr 2026
Die Datenlage ist eindeutig, auch wenn Marketingmaterial oft etwas anderes suggeriert: WAF und API Gateway sind keine austauschbaren Alternativen, sondern ergänzende Schichten mit unterschiedlichen Stärken. Für reine Webanwendungen ohne nennenswerte API-Oberfläche bleibt eine WAF die richtige, kosteneffiziente Wahl, mit Einstiegspreisen ab 20 Dollar im Monat bei Cloudflare. Sobald Kundendaten über APIs fließen, wie bei den 83 Prozent der deutschen Unternehmen, die laut Akamai bereits einen API-Vorfall hatten, reicht das allein nicht mehr.
Die drei Fälle T-Mobile, Optus und Peloton zeigen ein wiederkehrendes Muster: Der Schaden entstand nicht, weil eine WAF fehlte, sondern weil die API selbst keine ausreichende Autorisierungsprüfung hatte. Genau das ist die Aufgabe eines API Gateways. Wer beide Schichten kombiniert und dabei, wie NIST empfiehlt, doppeltes Parsing vermeidet, bekommt für einen Aufpreis von grob 1 bis 3 Dollar pro Million Anfragen ein deutlich robusteres Sicherheitsniveau. Angesichts von 470.000 Euro durchschnittlichem Schaden pro API-Vorfall in Deutschland ist das eine der besser kalkulierbaren Investitionen in der IT-Sicherheit.
Für die Praxis lässt sich das Urteil auf drei Kernaussagen verdichten. Erstens: Eine WAF ist Pflicht für jede öffentlich erreichbare Anwendung, unabhängig davon, ob sie APIs bereitstellt, weil sie automatisierte Angriffe und bekannte Exploits mit minimalem Aufwand abfängt. Zweitens: Ein API Gateway ist Pflicht, sobald eine API personenbezogene oder geschäftskritische Daten ausliefert, weil nur dort Autorisierung auf Objektebene technisch durchsetzbar ist. Drittens: Die Kombination beider Schichten, korrekt aufeinander abgestimmt, ist 2026 der de facto Standard für alles, was über eine reine Marketing-Website hinausgeht, gestützt durch NIST-Richtlinien, Branchendaten von Salt Security und Akamai sowie durch die NIS2-Erwartungen der Aufsichtsbehörden in Deutschland.
Häufig gestellte Fragen
Brauche ich sowohl eine WAF als auch ein API Gateway?
Für reine Webseiten ohne API reicht meist eine WAF. Sobald APIs sensible Daten ausliefern, empfiehlt NIST die Kombination beider Schichten, um sowohl Payload-Angriffe als auch Autorisierungsfehler abzudecken.
Was kostet eine WAF im Vergleich zu einem API Gateway?
Cloudflare WAF startet bei 20 Dollar pro Monat und Domain. AWS API Gateway kostet je nach Typ zwischen 1 und 3,50 Dollar pro Million Aufrufe, Kong Gateway ist als Open-Source-Variante kostenlos.
Schützt eine WAF vor BOLA- und IDOR-Angriffen?
Kaum. Diese Angriffe nutzen technisch korrekte Anfragen mit falscher Autorisierung, was eine signaturbasierte WAF in der Regel nicht erkennt. Das ist die Domäne des API Gateways mit Autorisierungs-Policies.
Welches Produkt eignet sich für kleine Unternehmen?
Cloudflare Pro für die WAF-Seite und Kong Gateway Open Source für das Routing sind ein kostengünstiger Einstieg, bevor größere Volumen einen Umstieg auf kostenpflichtige Tarife nötig machen.
Ist Kong Gateway wirklich kostenlos?
Die Open-Source-Version unter Apache-2.0-Lizenz ist kostenlos und selbst gehostet. Konnect Plus als verwalteter Cloud-Dienst kostet ab rund 105 Dollar pro Monat und Gateway-Service.
Was bedeutet NIS2 für WAF- und API-Sicherheit in Deutschland?
Seit Dezember 2025 gilt für rund 29.500 Unternehmen in Deutschland eine MFA-Pflicht im Rahmen von NIS2. Aufsichtsbehörden erwarten dokumentierte, mehrschichtige Schutzkonzepte, eine WAF allein erfüllt das in der Regel nicht.
Wie stark erhöht eine zusätzliche WAF-Schicht die Latenz?
Öffentliche, standardisierte Latenzbenchmarks für den direkten Vergleich fehlen bislang. NIST warnt aber ausdrücklich vor doppeltem Parsing bei getrennten WAF- und Gateway-Schichten und empfiehlt, WAF-Funktionen möglichst nah am oder im Gateway zu betreiben, um diesen Overhead zu reduzieren.
Kann ein API Gateway eine WAF komplett ersetzen?
Nur mit zusätzlichen Sicherheitsmodulen für Payload-Inspektion. Ohne solche Erweiterungen fehlt einem reinen Gateway der Schutz gegen klassische Injection- und Bot-Angriffe, den eine WAF standardmäßig mitbringt.
Was ist WAAP und unterscheidet es sich von einer klassischen WAF?
WAAP steht für Web Application and API Protection und bündelt WAF, Bot-Management, DDoS-Schutz und teils API-Discovery in einem Produkt, etwa bei Akamai oder Cloudflare. Die Tiefe der API-spezifischen Kontrollen unterscheidet sich dabei je nach Anbieter deutlich und sollte vor Vertragsabschluss geprüft werden.
Wer sollte WAF und API Gateway im Unternehmen betreuen?
Am besten ein gemeinsamer Prozess zwischen Security- und Plattformteam mit abgestimmtem Regelwerk. Getrennte Silos ohne gemeinsames Logging sind die häufigste Ursache für doppelte Prüfungen und blinde Flecken bei der Angriffserkennung.
