API-Sicherheit an der Edge: REST und GraphQL vor Missbrauch schützen

APIs sind die Angriffsfläche, die niemand im Browser sieht

Die meisten Sicherheitsdiskussionen drehen sich um Webseiten — um das, was ein Nutzer im Browser anklickt. Der Verkehr aber, der Ihr Geschäft trägt, läuft längst über APIs: Mobile-Apps, Partner-Integrationen, Single-Page-Frontends, Machine-to-Machine-Aufrufe. Diese Endpunkte haben keine sichtbare Oberfläche, keine Warnbanner, keinen menschlichen Nutzer, der stutzt, wenn etwas seltsam aussieht. Genau das macht sie zur bevorzugten Angriffsfläche: eine API missbraucht man leise, in großem Maßstab und ohne Zeugen.

Der Schutz gehört deshalb dorthin, wo der API-Verkehr ohnehin durchläuft — an die Edge, vor Ihre Anwendung, nicht als Bibliothek in jeder einzelnen Codebasis.

REST: die Anfrage lesen, nicht nur durchreichen

Ein REST-Endpunkt nimmt strukturierte Eingaben entgegen, und jede Eingabe ist eine potenzielle Injektion. An der Edge inspizieren zwei Signatur-WAF-Engines — eine in einer prozessinternen WASM-Sandbox, eine nativ — jede Anfrage gegen das OWASP Core Rule Set: SQL-Injection in einem Query-Parameter, ein Command-Injection-Versuch in einem JSON-Feld, ein Pfad-Traversal in einer vermeintlich harmlosen ID. Das passiert, bevor die Anfrage Ihr Origin erreicht — die Anwendung muss den Angriff gar nicht erst abwehren, weil er sie nie sieht.

Wichtiger noch als die einzelne bösartige Anfrage ist oft das Muster: dieselbe Quelle, die systematisch Endpunkte durchprobiert, IDs hochzählt oder Fehlermeldungen als Orakel benutzt. Solche Automatisierung fängt eine Ratenkontrolle ab, die pro Mandant, pro Route und pro Quelle zählt — dazu gleich mehr.

GraphQL: eine einzige URL, viele Risiken

GraphQL bricht die klassische Annahme, ein Endpunkt entspreche einer Operation. Hinter einer einzigen URL steckt eine ganze Abfragesprache — und damit eigene Angriffsklassen: tief verschachtelte Queries, die den Resolver in eine Ressourcenspirale treiben, aliasbasierte Verstärkung, die eine teure Operation dutzendfach in einer Anfrage bündelt, oder Introspection, die einem Angreifer das gesamte Schema ausleuchtet.

An der Edge lässt sich das eindämmen, ohne den GraphQL-Server anzufassen: verdächtig große oder tief geschachtelte Payloads werden erkannt, missbräuchliche Wiederholungsmuster laufen in die Ratenkontrolle, und automatisierter Abfrage-Missbrauch trifft dieselbe Challenge-Leiter wie jeder andere Bot-Verkehr. Sie härten die API, ohne jeden Resolver einzeln absichern zu müssen.

Missbrauch bremsen, ohne legitime Clients zu bestrafen

Der schwierige Teil von API-Sicherheit ist nicht das eindeutig Böse — das fängt eine Signatur. Schwierig ist der Missbrauch legitimer Endpunkte: der geleakte API-Schlüssel, der plötzlich das Zehnfache abruft, der Partner, dessen Integration Amok läuft, das Credential-Stuffing gegen den Login. Eine mehrstufige Ratenkontrolle — Shared-Memory-Zähler zuerst, verteilte Zähler dahinter — erkennt die Abweichung vom normalen Ruf-Profil und drosselt gezielt die Quelle, nicht den ganzen Endpunkt. Wie das Credential-Stuffing im Detail gestoppt wird, steht in unserem Beitrag zur Ratenkontrolle gegen Credential-Stuffing.

Jede Drossel- und Blockentscheidung landet in einem unveränderlichen, nur-anfügenden Audit-Log — inklusive Mandant, Route und Grund. Für einen deutschen Betreiber ist das der belegbare Unterschied zwischen „wir haben etwas geblockt“ und „wir können nachweisen, was, wann und warum“. Die gesamte Verarbeitung bleibt auf EU-Edge-Nodes, DSGVO-konform als Architekturvorgabe.

Ehrlich über die Grenzen

Eine Edge-WAF ersetzt keine saubere Authentifizierung und keine Autorisierungsprüfung in Ihrer Anwendung. Wenn ein Endpunkt fremde Datensätze herausgibt, weil die Objektberechtigung fehlt, ist das ein Logikfehler in Ihrem Code — den kann keine Firewall an der Edge erraten, weil sie Ihre Geschäftsregeln nicht kennt. Was wir übernehmen, ist die Schicht davor: Injektion, automatisierter Missbrauch, Enumeration, Flood. Diese Filterung bleibt im Design-Budget von ≤5 ms; wie wir das messen, steht in der Latenz-Methodik.

Wenn Ihre API die eigentliche Angriffsfläche ist, nennen Sie uns Ihre Domain — oder sehen Sie sich an, wie es funktioniert.