24. Rate Limits

Da die öffentlichen Endpunkte (20-api.md) ohne API-Key auskommen, schützt PRONTO sie stattdessen mit einem mehrstufigen Missbrauchsschutz — identisch implementiert für Formular-Einsendungen und Newsletter-Anmeldungen:

1. Honeypot

Ein unsichtbares Feld (website), das echte Nutzer nie ausfüllen. Ist es befüllt, gilt die Einsendung als Bot-Traffic.

2. Mindest-Ausfüllzeit

ladezeitMs — die Zeit zwischen Anzeige des Formulars und Absenden. Unter 1200 ms gilt eine Einsendung als automatisiert und wird verworfen.

3. IP-basiertes Rate-Limit

Pro SHA-256-Hash der Absender-IP (aus cf-connecting-ip/x-forwarded-for, die IP-Adresse selbst wird nie gespeichert): maximal 5 Einsendungen pro 5 Minuten je Formular/ Newsletter-Anmeldung desselben Kunden.

Verhalten bei Erkennung

Erkennung	Antwort
Honeypot befüllt oder Ausfüllzeit < 1200 ms	`200 { "status": "ok" }` — bewusst als Erfolg getarnt, damit Bots den Unterschied nicht erkennen
Echtes IP-Rate-Limit erreicht	`429` — für echte Nutzer sichtbar, da es sich um einen erkennbaren Grenzfall handelt (z. B. Formular versehentlich mehrfach abgeschickt)

Praktische Hinweise für eigene Integrationen

Das website-Feld beim eigenen Nachbau immer leer mitsenden.
ladezeitMs ehrlich aus der tatsächlichen Anzeigedauer berechnen — ein statischer, zu niedriger Wert lässt echte Einsendungen als Spam durchfallen.
Bei automatisierten Massen-Tests (z. B. Integrationstests) das 5-Minuten-Fenster einplanen, sonst greift ab der 6. Anfrage derselben IP 429.

Andere Endpunkte

Buchungsseiten (kalender/buchen) und das Chat-Widget haben aktuell kein IP-Rate-Limit — Missbrauchsschutz erfolgt dort über Tenant-Isolation und (beim Widget) Domain-Prüfung (domainErlaubt) sowie Credit-Verbrauch bei KI-Antworten.