Eine B2B-API ist kein Webauftritt, der mal kurz langsam sein darf. An ihr hängen die Produkte anderer Firmen. Mit eigenen Kunden und eigenen SLAs. Bricht die API unter einem Angriff zusammen, brechen diese SLAs mit. Der Schaden entsteht dann nicht auf einer Website, sondern in den Verträgen.
Der Standard-Reflex lautet: Rate-Limits. Die hat jede API ohnehin. Gegen moderne Angriffe reichen sie nicht, und das hat strukturelle Gründe.
Warum Rate-Limits nicht reichen
Ein L7-Flood auf eine API besteht aus gültigen Requests, korrektes TLS, korrekte Header, plausible Payloads, nur eben zu viele davon, aus zehntausenden Quellen gleichzeitig. Genau daran scheitern Rate-Limits:
- Pro-IP-Limits laufen ins Leere. Botnetze rotieren über zehntausende IPs. Jede einzelne bleibt unter dem Limit. Die Summe legt Ihr Backend trotzdem lahm.
- Scharfe Limits treffen die Falschen. Drehen Sie die Limits herunter, sperren Sie zuerst Ihre größten legitimen Kunden aus. Die mit dem höchsten Request-Volumen.
- Das Limit greift zu spät. Rate-Limiting passiert auf Ihrer Infrastruktur. Der Angriffs-Traffic ist dann schon da. TLS-Handshakes, Connection-State, CPU. Bei genügend Volumen stirbt der Server am Zählen.
Rate-Limits sind Hygiene gegen fehlkonfigurierte Clients und einfache Scraper. Sie sind kein DDoS-Schutz.
Was stattdessen schützt
Der Schutz muss vor der Infrastruktur sitzen und Angreifer von legitimen Clients unterscheiden, ohne die API kaputtzufiltern. Bei ZERO-PROTECT heißt das konkret:
JA4-Fingerprinting. TLS- und HTTP-Fingerprints identifizieren Bot-Frameworks unabhängig von der IP. Ein Botnetz kann Adressen rotieren. Seinen TLS-Stack rotiert es nicht so leicht. So lässt sich Angriffs-Traffic filtern, während der API-Client Ihres Großkunden ungestört weiterarbeitet.
Proof-of-Work-Challenges. Für verdächtige Quellen lässt sich eine kleine Rechenaufgabe vorschalten. Legitime Clients lösen sie einmalig und unmerklich. Für ein Botnetz mit Millionen Requests wird genau das teuer, was den Angriff bisher billig machte.
Scrubbing vor Ihrem Netz. Volumetrische Angriffe und Protokoll-Floods werden auf unserem Netz (AS215197) gefiltert, bevor sie Ihre Anbindung erreichen. Ihr Backend sieht nur bereinigten Traffic. Die zehn Mitigationsschichten dahinter haben wir in So funktioniert ZERO-PROTECT beschrieben.
Und weil APIs keine Browser bedienen: Der Schutz kommt ohne Browser-Checks und Captchas aus, die Machine-to-Machine-Traffic zerstören würden.
Die SLA-Rechnung
Rechnen Sie es einmal durch, und zwar nicht mit einer Stunde. Anhaltende Angriffe laufen in Wellen über zwei, drei Tage. Ein Verfügbarkeits-SLA von 99,9% erlaubt rund 43 Minuten Ausfall im Monat: Ein einziger Angriffstag verbrennt das Budget von mehr als zwei Jahren. Was das über alle Kunden-SLAs kostet (Gutschriften, Pönalen, Eskalationsaufwand) steht auf der Rechnung. Was nicht draufsteht: Ein B2B-Kunde, dessen eigenes Produkt drei Tage lang wegen Ihrer API wackelte, plant beim nächsten Renewal einen zweiten Anbieter ein.
Diese Zahl gegen die monatlichen Kosten für echten Schutz. Das ist die ganze Entscheidung. Wie sich die Angriffe selbst entwickelt haben, zeigt Was DDoS-Angriffe wirklich kosten.
NIS2 für API-Anbieter
Viele API-Anbieter fallen als IKT-Dienstleister oder digitale Infrastruktur in den NIS2-Scope (ab 50 Mitarbeitenden oder 10 Mio.€ Umsatz). Dann ist Angriffsabwehr Teil des Pflicht-Risikomanagements, und „wir haben Rate-Limits“ dürfte in einem Audit eine kurze Diskussion werden. Warum auch Blackholing als Alleinlösung nicht trägt, steht in Wenn dein DDoS-Schutz dich blackholt.
ZERO-PROTECT für APIs
JA4-Fingerprinting, PoW-Challenges, Scrubbing vor Ihrer Infrastruktur, ohne Browser-Checks, die M2M-Traffic brechen. BSI-qualifiziert, DSGVO-konform, auf eigenem Netz (AS215197).