Daten, Datenschutz & Sicherheit › Rate-Limiting (Missbrauchsbremse)
Rate-Limiting (Missbrauchsbremse)
SicherheitLive✓ Geprüft am Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)Ruft jemand einen offenen Zugang zu oft in kurzer Zeit auf — Kontaktformular, Kundenlink, Tablet-Anmeldung —, bremst das System ihn automatisch und antwortet für eine Weile mit einer Warteaufforderung. Das macht automatisiertes Durchprobieren und Spam unpraktikabel.
Bild folgt
Vor der eigentlichen Arbeit fragt ein Endpunkt zuerst die Bremse. Sie zählt die Aufrufe je Schlüssel in einem Zeitfenster; ein Schlüssel ist meist die Adresse des Anrufers, oft zusätzlich der verwendete Zugangs-Code, damit ein einzelner Code nicht dauerhaft gehämmert werden kann. Wird die Grenze überschritten, kommt eine Absage mit dem Hinweis, wie lange zu warten ist, und je nach Endpunkt eine kurze Sperrzeit obendrauf. Nach einer erfolgreichen Anmeldung wird der Zähler geleert, damit ein Vertipper nicht nachwirkt. Die Adresse des Anrufers wird nicht blind aus den Kopfzeilen der Anfrage übernommen: Weiterleitungsangaben zählen nur, wenn die unmittelbare Gegenstelle als vertrauter Vorschaltserver bekannt ist, sonst könnte jeder eine fremde Adresse behaupten und die Bremse aushebeln. Fehlt diese Vertrauensliste im Betrieb, warnt das System beim Start. Gezählt wird wahlweise im Arbeitsspeicher — schnell, aber nach jedem Neustart leer — oder in der Datenbank, wo der Stand einen Neustart übersteht. Geschützt sind unter anderem die Links des Kundenportal, das Anfrageformular der Öffentliche Website und die Anmeldung des Mechaniker-Tablet.
- Ein Kunde bekommt „Zu viele Anfragen. Bitte kurz warten." → die Grenze ist erreicht; die Antwort nennt die Wartezeit, danach geht es wieder.
- Mehrere Mitarbeiter oder Kunden desselben Anschlusses werden gleichzeitig gebremst → sie erscheinen nach außen unter einer Adresse und teilen sich einen Zähler.
- Alle Besucher landen im selben Zähler und blockieren sich gegenseitig → dann werden die Weiterleitungsangaben des Vorschaltservers verworfen; die Vertrauensliste im Betrieb muss gesetzt werden.
- Nach einem Neustart ist eine Sperre plötzlich weg → beim Zähler im Arbeitsspeicher ist das erwartbar; wer Sperren über Neustarts halten will, muss auf die Datenbank umstellen.
- Ob in Produktion der Zähler im Arbeitsspeicher oder in der Datenbank läuft, sagen die gelesenen Quellen nicht. Beim Arbeitsspeicher-Zähler beginnt nach jedem Neustart alles bei null.
- Ob die Liste der vertrauten Gegenstellen in Produktion gesetzt ist, wurde nicht geprüft. Der Code warnt beim Start, wenn sie fehlt — der Nachweis eines solchen Laufs fehlt hier.
- Eine Gesamtübersicht aller Endpunkte mit Bremse und ihrer Grenzwerte existiert nicht; geprüft wurden das Kundenportal, das Kontaktformular und die Mechaniker-Wege.
- lib/rate-limit.ts
- lib/mechanic-rl.ts
- app/api/angebot/[token]/route.ts
- app/api/contact/route.ts
| mechanismus | clientIpFrom() ermittelt die Client-Adresse spoof-sicher, danach rateLimit() (gleitendes Fenster, Arbeitsspeicher) bzw. rateLimitDb() (fixes Fenster, SQLite) je nach RATE_LIMIT_STORE; rlHit() ist der fertige 429-Wrapper fuer die Tablet- und Mechaniker-Wege |
|---|---|
| speicher | Arbeitsspeicher (Standard) oder SQLite; Arbeitsspeicher-Zaehler sind nach einem Neustart leer |
Beleg: lib/rate-limit.ts: gleitendes Fenster im Arbeitsspeicher (Standard) oder SQLite-Tabelle rate_limit_buckets ueber RATE_LIMIT_STORE; clientIpFrom() traut Weiterleitungs-Kopfzeilen nur von vertrauten Gegenstellen; lib/mechanic-rl.ts::rlHit liefert 429 mit Retry-After; app/api/angebot/[token]/route.ts:28 rateLimit 30/min mit 60 s Abkuehlung; app/api/contact/route.ts importiert rate-limit
Tiefer fragen
Kontext aus dem KFZ-Bozo-Handbuch
Knoten: sec-rate-limit (Sicherheit · Daten, Datenschutz & Sicherheit · live · geprüft Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) @ 0f0406a1)
Kurz: Ruft jemand einen offenen Zugang zu oft in kurzer Zeit auf — Kontaktformular, Kundenlink, Tablet-Anmeldung —, bremst das System ihn automatisch und antwortet für eine Weile mit einer Warteaufforderung. Das macht automatisiertes Durchprobieren und Spam unpraktikabel.
Lies zuerst (Lesebereich, nicht der ganze Baum):
lib/rate-limit.ts
lib/mechanic-rl.ts
app/api/angebot/[token]/route.ts
app/api/contact/route.ts
Hängt zusammen mit:
data-system-audit (lib/db/schema.ts) · sec-ip-blocks (app/api/admin/ip-blocks) · sec-mechaniker-pin (lib/db/tablet-session.ts) · sec-kunden-token (lib/db/customer-tokens.ts) · api-oeffentlich-system (app/api/health) · feat-portal-bericht (app/bericht/[token]/page.tsx)
Offene Fragen der Seite:
Ob in Produktion der Zähler im Arbeitsspeicher oder in der Datenbank läuft, sagen die gelesenen Quellen nicht. Beim Arbeitsspeicher-Zähler beginnt nach jedem Neustart alles bei null.
Ob die Liste der vertrauten Gegenstellen in Produktion gesetzt ist, wurde nicht geprüft. Der Code warnt beim Start, wenn sie fehlt — der Nachweis eines solchen Laufs fehlt hier.
Eine Gesamtübersicht aller Endpunkte mit Bremse und ihrer Grenzwerte existiert nicht; geprüft wurden das Kundenportal, das Kontaktformular und die Mechaniker-Wege.
Hausregel 2: Vault-Daten sind für diese Session unsichtbar; Quellpfade auf Vault-Code sind keine Freigabe.
Frage: {{DEINE FRAGE}}
Antworte nur mit Belegen: nenne Datei und Zeile für jede Aussage.
Wenn die Quellen die Frage nicht beantworten, sag das und nenne, was du zusätzlich lesen müsstest.
Weicht die Seite vom Code ab, schlage den Seiten-Patch vor (wiki/seiten/daten-recht-sicherheit/sec-rate-limit.md).