PPartnerDesk

91 — Rate-Limiting

Aktualisiert am 1. Juni 2026

91 — Rate-Limiting

PartnerDesk schützt sich und seine Tenants gegen Brute-Force-Angriffe und Spam durch zentrale Rate-Limits.

Was wird limitiert?

Endpoint Limit Identifier
Login (alle drei: Superadmin, Admin, Partner) 5/Min IP + Email
Webhook (alle Provider) 120/Min IP + Tenant + Provider
Public-API 600/Min API-Key-UUID
Signup 10/Stunde IP
Tracking-Pixel (Klick-Erfassung) 1000/Min IP
Forgot-Password 5/Stunde Email + IP

Was passiert bei Überschreitung?

  • HTTP-Status 429 Too Many Requests.
  • Retry-After-Header zeigt, wie viele Sekunden bis zum nächsten Versuch.
  • Im Webhook-Fall: der Provider versucht üblicherweise automatisch erneut nach Backoff.

Warum diese Limits?

Login (5/Min)

Brute-Force-Schutz. Auch wenn ein Angreifer das Passwort errät, kann er es nur 5× pro Minute versuchen — bei einem 8-stelligen Passwort dauert das Jahrhunderte.

Webhook (120/Min)

Schutz vor Provider-Storms. Bei einem Migrations-Lauf oder Test-Burst können Sales-Webhooks im Minutentakt eintreffen. 120/Min reicht für legitime Spitzen, blockiert aber Endlos-Schleifen.

Public-API (600/Min)

Pro API-Key. Verhindert, dass ein Tenant durch fehlerhaften Code (z. B. Endlos-Loop) die Plattform überlastet.

Signup (10/Stunde)

Schutz vor Massen-Spam-Signups, die das System mit Fake-Tenants fluten würden.

Tracking (1000/Min)

Großzügig. Schutz vor Bot-Spam auf Tracking-Pixeln. Echte User generieren niemals 1000 Klicks pro Minute.

Forgot-Password (5/Stunde)

Verhindert Email-Spam. Wenn ein Angreifer die Email eines Users kennt, kann er nicht beliebig oft Reset-Mails an die Person schicken.

Storage

Alle Limits werden in Redis gespeichert. Damit:

  • Multi-Instance-fähig (mehrere App-Container teilen sich denselben Counter).
  • Sehr schnell (Redis-In-Memory).

Token-Bucket vs. Sliding-Window

  • Login: Token-Bucket — 5 Tokens, alle 12 s wird einer aufgefüllt.
  • Webhook, API, Tracking: Sliding-Window — wie viele Requests in den letzten 60 s.

Beide Strategien sind robust gegen Burst-Attacken.

Was Sie als Tenant erleben

Im Normalbetrieb merken Sie nichts. Die Limits sind so gewählt, dass legitime Nutzung nie betroffen ist.

Wenn doch:

  • Eigener Workflow-Bot überschreitet API-Limit → Code anpassen (Throttle, Pagination).
  • Provider sendet zu viele Webhooks → mit dem Provider klären, wenn unerwartet.

Was Sie als Partner erleben

Bei falsch eingegebenem Passwort: nach 5 Fehlversuchen wartet der Login eine Minute.

Bei DDoS

Echte DDoS-Angriffe (massiv hohe Request-Zahlen aus vielen Quellen) behandelt nicht das Rate-Limiting allein, sondern:

  • Cloudflare (oder ähnlicher CDN-/DDoS-Schutz vor PartnerDesk).
  • Hetzner DDoS-Protection (Server-Provider-Level).
  • Caddy/Nginx-Rate-Limit (Reverse-Proxy-Level).

Mehrstufiger Schutz, das eigentliche App-Rate-Limit ist die letzte Verteidigungslinie.

Verwandte Kapitel

Technische Tiefen-Doku: ../028-rate-limit-2fa-sentry.md, ../125-rate-limit-public.md