Blog · API-Sicherheit und Betrieb ·
API Rate Limiting für Kundenanwendungen: Missbrauch und Kosten begrenzen
API Rate Limiting begrenzt, wie oft eine Identität eine Aktion in einem Zeitfenster ausführen darf. Für ein Kundenportal reicht ein pauschales Limit pro IP häufig nicht: Exporte, Dateiverarbeitung oder KI-Aufrufe brauchen eigene Grenzen. Ein lokales CRM-Beispiel zeigt Nutzer- und Mandantenquoten, korrekte Ablehnungen und kontrollierte Wiederfreigabe.
Welche Aktionen brauchen zuerst ein Limit?
Beginnen Sie mit den Aktionen, deren wiederholte Ausführung Geld kostet, andere Nutzer blockiert oder große Datenmengen bewegt. Im fiktiven Agentur-CRM sind das Kontaktexporte und die spätere Zusammenfassung von Gesprächsnotizen. Das Öffnen einer kleinen Profilansicht hat andere Folgen als ein vollständiger Export. Beide hinter dieselbe Zahl „Anfragen pro Minute“ zu stellen, verdeckt diesen Unterschied.
Erfassen Sie für jeden solchen Ablauf den aufrufenden Nutzer, die betroffene Organisation, die erlaubte Datenmenge und die nachgelagerte Arbeit. Wird eine externe API berechnet? Läuft ein Hintergrundjob weiter, nachdem die HTTP-Verbindung beendet wurde? Können zehn kleine Anfragen gemeinsam einen großen Auftrag starten? Diese Fragen bestimmen, an welcher Stelle ein Limit wirksam sein muss.
OWASP beschreibt unbeschränkten Ressourcenverbrauch als API-Risiko, das Verfügbarkeit und Betriebskosten betrifft. Dazu gehören neben der Anfragerate unter anderem Datenmengen, Arbeit pro Anfrage und Ausgaben bei angebundenen Diensten. Unser Beispiel konzentriert sich auf einen kleinen Ausschnitt: die Zulassung eines begrenzten Exports.
Nutzerquote, Mandantenquote und Kostengrenze unterscheiden
Eine Nutzerquote verhindert, dass ein einzelnes Konto das gesamte Exportkontingent verbraucht. Eine zusätzliche Mandantenquote begrenzt die gemeinsame Nutzung durch mehrere Konten desselben Kunden. Eine Kostengrenze betrachtet dagegen die verursachte Arbeit: Ein Export mit hundert Datensätzen oder ein langer KI-Auftrag kann deutlich mehr Ressourcen benötigen als ein kleiner Aufruf.
| Grenze | Im lokalen Beispiel | Im Kundenprojekt klären |
|---|---|---|
| Nutzer | 3 Exporte je 60-Sekunden-Fenster | Normale Arbeit, Automationen und berechtigte Spitzen |
| Organisation | 5 Exporte je Fenster, über alle Konten | Gemeinsames Kontingent und faire Verteilung |
| Einzelne Anfrage | Höchstens 1.024 Body-Bytes und 100 angeforderte Datensätze | Upload, Seitengröße, Batch-Anzahl und Laufzeit |
| Externe Kosten | Kein externer Dienst aufgerufen | Budget, reservierte Kosten und Verhalten am Limit |
Die kleinen Zahlen machen Gegenproben schnell nachvollziehbar. Sie sind keine Kapazitätsplanung. Für echte Projekte bestimmen normale Nutzung, Vertrag und gemessene Last die Werte. Ein Monatsbudget mit verzögerter Abrechnung ist außerdem kein präzises Echtzeitlimit: Bereits gestartete Aufträge können weiter Kosten verursachen.
Die Anwendung muss wissen, wen sie begrenzt
Die Organisation muss aus einer geprüften Sitzung und Mitgliedschaft
stammen.
Ein frei gesetzter Header wie X-Tenant: beta darf weder
Berechtigungen noch ein neues Kontingent schaffen. Im Beispiel ordnet eine
ausschließlich serverseitige Tabelle synthetische Sitzungstokens den Nutzern
Alice, Anna und Bob zu. Alice und Anna gehören zu Alpha, Bob zu Beta.
Eine IP-Adresse kann für unauthentifizierte Zugriffe ein zusätzliches Signal sein. Hinter einem Agenturbüro oder Mobilfunkzugang teilen sich jedoch mehrere Personen eine Adresse. Umgekehrt können Adressen wechseln. Weitergereichte Client-IP-Header dürfen nur über den tatsächlich vertrauenswürdigen Proxy-Pfad ausgewertet werden. Eine vom Internet direkt erreichbare Anwendung darf solchen Angaben nicht blind vertrauen.
Auch ein Kontingent ersetzt keine fachliche Erlaubnis: Der Partner im Beispiel
darf überhaupt keinen Export starten und erhält 403. Erst nach
Authentifizierung, Berechtigungsprüfung und Eingabevalidierung wird das
Exportkontingent belastet. Den vorgelagerten Schutz gegen große Mengen ungültiger
Anfragen muss ein reales System zusätzlich lösen. Die
Zugriffspfade eines internen CRM helfen
dabei, direkte APIs und Umgehungswege zu erfassen.
Zulassung und Zähler müssen zusammenpassen
Die Beispielanwendung prüft Nutzer- und Mandantenzähler unter derselben Sperre. Nur wenn beide noch Platz haben, erhöht sie beide Zähler und führt die modellierte Arbeit aus. Eine Ablehnung erhöht keinen Arbeitszähler. So kann ein gleichzeitig eintreffender Aufruf nicht zwischen Prüfung und Abbuchung unbemerkt das Kontingent überschreiten.
Identität prüfen → Exportrecht prüfen → Eingabe begrenzen
→ Nutzer- und Mandantenquote gemeinsam prüfen und abbuchen
→ Arbeit starten oder HTTP 429 zurückgebenDiese atomare Entscheidung gilt hier für einen Python-Prozess. Mehrere Serverinstanzen benötigen einen gemeinsam wirksamen Mechanismus. Ein Zähler im Arbeitsspeicher jeder Instanz vervielfacht sonst das erlaubte Kontingent. Auch Neustarts, alte Zähler und Ausfälle des gemeinsamen Speichers gehören in den Entwurf. Legen Sie je Aktion fest, ob ein Ausfall weitere Arbeit sperrt oder vorübergehend ein eng begrenztes Ersatzkontingent zulässt.
Das verwendete feste Zeitfenster hat eine bekannte Grenze: Kurz vor und kurz nach dem Fensterwechsel können zwei Kontingente dicht aufeinanderfolgen. Die Artikel-Fixture zeigt diesen einfachen Algorithmus, keine gleichmäßige Verkehrsverteilung. Bei anderen Anforderungen kommen gleitende Fenster oder Token-Bucket-Verfahren infrage; zusätzlich kann eine eigene Grenze für gleichzeitig laufende Aufträge nötig sein.
Was sollte bei HTTP 429 passieren?
RFC 6585 definiert 429 „Too Many Requests“. Die Antwort sollte das Problem erläutern und darf mit
Retry-After angeben, wann ein neuer Versuch sinnvoll ist. Im Beispiel
ist dieser Wert eine Anzahl von Sekunden bis zum nächsten festen Fenster. Die
Antworten tragen außerdem Cache-Control: no-store.
Die Oberfläche sollte die abgewiesene Aktion verständlich erklären und den erneuten Versuch passend begrenzen. Automatisches sofortiges Wiederholen erzeugt zusätzliche Last. Bei schreibenden oder kostenpflichtigen Aktionen braucht es darüber hinaus eine klare Wiederholungsstrategie: Ein verlorener Erfolgsbescheid darf nicht versehentlich zwei abrechenbare Aufträge auslösen. Ein Idempotenzschlüssel löst dabei ein anderes Problem als eine Quote und benötigt eine eigene Prüfung.
Ein erschöpftes dauerhaftes Budget ist nicht zwingend in sechzig Sekunden wieder frei. Geben Sie in diesem Fall keinen erfundenen Wiederholungszeitpunkt aus. Benennen Sie stattdessen den fachlichen Zustand und den nächsten Schritt, etwa den nächsten Abrechnungszeitraum oder eine Freigabe durch den Verantwortlichen.
Das HTTP-Beispiel selbst ausführen
Speichern Sie den
Python-Runner
in einem eigenen Verzeichnis. Benötigt wird Python 3.10 oder neuer; zusätzliche
Pakete sind nicht erforderlich. Der Runner öffnet für den Test einen zufälligen
Port ausschließlich auf 127.0.0.1, erzeugt kurzlebige synthetische
Tokens und beendet den Server anschließend.
python3 run.py > results.jsonDer Runner akzeptiert keine Zieladresse und sendet keine Anfragen an ein Kundenprojekt. Er prüft echte lokale HTTP-Antworten. Den Fensterwechsel steuert die Testlogik über eine interne Uhr; es gibt keinen HTTP-Endpunkt zum Zurücksetzen der Quote. Die Gleichzeitigkeit wird mit einer gemeinsamen Startbarriere hergestellt, nicht mit Wartezeiten geraten.
Anleitung und Grenzen, aufgezeichnete Ergebnisse und MIT-Lizenz liegen neben dem Runner. Der Ergebnisdatensatz nennt die SHA-256-Prüfsumme des tatsächlich ausgeführten Quelltexts.
Welche Ergebnisse wurden beobachtet?
Am 28. September 2026 bestanden 19 Prüfungen. Alice konnte drei Exporte starten; weitere Anfragen wurden abgewiesen. Anna nutzte die beiden verbleibenden Plätze der gemeinsamen Alpha-Quote. Bob konnte bei Beta weiterhin arbeiten. Ein gefälschter Mandanten- oder Client-IP-Header änderte Alices ausgeschöpftes Kontingent nicht.
Zehn gleichzeitig gestartete Anfragen desselben Nutzers führten im frischen
Fenster zu genau drei Erfolgen und sieben Antworten mit 429. Der
Arbeitszähler stieg nur um drei. Die Gegenproben für anonyme Nutzer, fehlendes
Exportrecht, zu große Bodies und zu viele Datensätze erreichten die modellierte
Exportarbeit nicht. Nach dem kontrollierten Fensterwechsel war ein neuer Export
möglich.
Das ist kein Lasttest und kein Nachweis für verteilte Instanzen. Das Beispiel begrenzt weder offene Verbindungen noch den gesamten Speicherverbrauch eines Servers. Es implementiert keine produktive Anmeldung, persistente Kontingente, Warteschlange oder echte Abrechnung. Die kleine feste Nutzerzahl verhindert hier auch nicht allgemein ein Wachstum der Zählertabelle. Diese Grenzen gehören in die Übertragung auf ein reales System.
Was gehört in die Abnahme des Kundenprojekts?
- Normale Nutzung: Der berechtigte Ablauf funktioniert vor Erreichen des Limits. Die gewählten Grenzen sind mit der Agentur und dem Betreiber abgestimmt.
- Identitäten und Organisationen: Mehrere Nutzer teilen das richtige Kundenkontingent; eine andere Organisation bleibt unabhängig. Frei gesetzte Header verändern diese Zuordnung nicht.
- Grenzen und Gleichzeitigkeit: Der Grenzfall und parallele Aufrufe werden über den echten Endpunkt geprüft. Abgewiesene Aufrufe starten keine teure Arbeit.
- Mehrere Instanzen: Routing auf einen anderen Server, ein Neustart und der Ausfall des Zählers entsprechen dem vereinbarten Verhalten.
- Folgewirkungen: Wiederholungen, Hintergrundjobs und externe Kosten bleiben begrenzt. Eine Alarmierung benennt Aktion und Organisation ohne Zugangsdaten mitzuschreiben.
- Betrieb: Jemand verantwortet Kontingentänderungen, Supportfälle und die Kontrolle realer Nutzung. Abweichungen von der geprüften Konfiguration werden dokumentiert.
Verknüpfen Sie diese Nachweise mit der Software-Übergabe. Die RLS-Gegenproben prüfen ergänzend, welche Daten ein Konto überhaupt erreichen darf. Weniger Anfragen an eine falsch autorisierte Daten-API bleiben falsch autorisierte Anfragen.
Wo passt obhut in das Kundenprojekt?
obhut entwickelt die Betriebsplattform für Agenturen mit Websites, Portalen, SaaS und internen Anwendungen. Statisches Hosting sowie HTTP/HTTPS-Proxy und Tunnel sind implementiert; die Plattform läuft im Pilotbetrieb: Konten lassen sich anlegen, ein SLA gibt es noch nicht.
Identitätsbasierter Access, WAF und Rate Limits für Kundentraffic sowie Serverlaufzeiten sind geplant. Ein Frontend-Proxy konfiguriert keine Datenbankrechte und schützt keine API außerhalb seines Anfragewegs. Die hier gezeigten Beispiele sind eigenständige Lehrmaterialien und keine verfügbaren obhut-Sicherheits- oder Backupdienste.
Im Projektgespräch für Agenturen klären wir anhand Ihrer Anwendung Laufzeit, Nutzer, Datenwege und Zuständigkeiten. Die Anfrage dient dem Projektabgleich; sie ist keine Sicherheitsfreigabe oder Buchung eines Audits.
Quellen und Prüfstand
Primärquellen geprüft am 28. September 2026. Die lokalen Ergebnisse und ihre Grenzen stehen im verlinkten Beispiel; Aussagen über einen Kundenbetrieb werden daraus nicht abgeleitet.
