← Zurück zur Übersicht

Rate Limit, Warteschlangen und Antispam für Formulare und Bots

Rate Limit, Warteschlangen und Antispam sind drei Schutzschichten - ohne sie werden Formulare und Telegram-/Discord-Bots schnell zu Kanälen für Spam, Flood und DoS. Ein CAPTCHA reicht nicht: Sie brauchen Frequenzlimits, asynchrone Verarbeitung sowie Filter nach Inhalt und Reputation. Unten - wie Sie ein praxistaugliches Setup für Sites und Bots ohne unnötige Komplexität bauen.

  • Rate Limit - wie viele Anfragen pro Zeitfenster von einer IP, einem Konto oder Token erlaubt sind
  • Warteschlange - Puffer zwischen Annahme der Anfrage und schwerer Arbeit (E-Mail, CRM, LLM, Webhook)
  • Antispam - Honeypot, CAPTCHA, Heuristiken, Blocklisten und Inhaltsprüfung
  • Regel - zuerst Frequenz drosseln und asynchron verarbeiten, dann Filter verschärfen
  • Ziel - echte Leads behalten und den Dienst unter einem Botnetz am Laufen halten

Warum Formulare und Bots zuerst angegriffen werden

Ein öffentlicher Endpoint ist eine unverschlossene Tür. Spam-Bots suchen /contact, /api/lead und Bot-Webhooks und senden Tausende Nachrichten: Phishing, SEO-Spam, Credential Stuffing, Promo-Code-Brute-Force. Ohne Limits steigen E-Mail-/SMS-/LLM-Kosten, das CRM füllt sich mit Müll, echte Leads ertrinken im Rauschen.

Typische Symptome:

  1. POST-Spike auf das Formular bei null Verkaufskonversionen
  2. Identische Texte von verschiedenen IPs - oder einzigartiger Müll aus einem Bereich
  3. E-Mail- oder Webhook-Warteschlangen treffen Provider-Limits
  4. Der Messenger-Bot antwortet langsamer oder mit Timeout

Rate Limit: was begrenzen und wie

Rate Limiting beantwortet: «Wie oft darf dieser Endpoint in N Sekunden getroffen werden?» Der Schlüssel der Begrenzung zählt.

Schlüssel Wann passend Risiko
IP Anonyme Formulare, Webhooks ohne Auth NAT und Firmennetze treffen gute Nutzer
User / chat_id Authentifizierte APIs und Bots Schützt nicht vor dem Login
API-Token / Session Partner-Integrationen Gestohlenes Token verbraucht das ganze Kontingent
Fingerprint + IP Harte Formular-Abwehr Schwerer einzuführen und zu erklären

Praktische Fenster:

  • Lead-Formular: 3-5 erfolgreiche Sends pro IP in 10 Minuten, plus hartes Limit für Fehlschläge (Validierung, CAPTCHA-Fail)
  • Login / OTP: separat und strenger - sonst Brute Force
  • Bot-Befehle: 1 schwere Antwort (Generierung, Suche) pro Nutzer alle paar Sekunden; leichte Befehle - weicher
  • Globale Decke auf Prozess oder Worker - schützt Spitzen, auch wenn Schlüssel differieren

Bei Überschreitung: HTTP 429 mit Retry-After; im Bot - kurze Meldung «warten Sie N Sekunden», ohne interne Schwellen zu verraten. Loggen Sie Treffer: sie zeigen, ob das Limit zu weich oder zu hart ist.

Warteschlangen: Annahme von Verarbeitung trennen

Das Formular soll nicht synchron ins CRM schreiben, ein PDF erzeugen und eine externe API rufen. Eine Warteschlange (Redis, RabbitMQ, SQS, Celery, BullMQ) nimmt den Job nach Validierung und antwortet schnell: «Anfrage angenommen».

Was die Queue bringt:

  • Spitzen glätten - Spam oder Kampagnen-Spike legt Web-Prozesse nicht lahm
  • Retry bei Fehlern - Retry mit Backoff statt verlorener Leads
  • Prioritäten - bezahlte Bestellungen vor «PDF herunterladen»
  • Isolation - LLM-/E-Mail-Worker skalieren getrennt vom Frontend

Formularfluss:

  1. CSRF / Origin, Honeypot, Basisvalidierung der Felder
  2. Rate Limit
  3. Lead in der DB mit Status queued speichern
  4. Push in die Queue
  5. HTTP 200/202 an den Nutzer
  6. Worker: Antispam-Scoring → CRM / E-Mail / Benachrichtigung

Dasselbe bei Bots: Telegram-Update schnell annehmen; schwere Antworten (RAG, Bild, Parsing) in die Queue. Sonst staut sich Long Polling / Webhook-Latenz.

Antispam: Schichten, nicht eine Checkbox

Ein reCAPTCHA schließt das Thema nicht. Bauen Sie Defense in Depth.

1. Günstige Filter am Eingang

  • Honeypot-Feld (für Menschen versteckt, von Bots gefüllt)
  • Minimale Ausfüllzeit (zu schnell = Bot)
  • Prüfung von Referer / Origin und CSRF-Token
  • Limit für Body-Größe und Anhänge

2. CAPTCHA und Challenges

Challenge auf Signal zeigen, nicht immer: nach N Versuchen, bei verdächtiger IP, bei hohem Score. Permanentes CAPTCHA trifft Conversion; gezieltes kaum.

3. Inhalt und Reputation

  • Domain-/URL-Blocklisten im Text
  • Erkennung wiederholter Vorlagen und sprachagnostischen Spams
  • E-Mail-Checks (MX, Disposable-Domains)
  • Bei Bots: Linkfilter, Stoppwörter, Media-Limits

4. Verhaltenssignale

Historie: wie viele Sends von diesem Gerät wurden Kauf oder sinnvoller Chat. Neue IP mit Dutzenden «buy seo» pro Minute - in Quarantäne oder manuelle Prüfung, nicht direkt ins CRM des Managers.

Die drei Schichten verbinden

Empfohlene Produktionsreihenfolge:

  1. Validierung und günstiger Antispam (Honeypot, Größe, CSRF)
  2. Rate Limit nach IP + User-/Chat-ID
  3. Schnelle Antwort an Client / Messenger
  4. Queue mit Concurrent-Job-Limit pro Worker
  5. Schwerer Antispam und Integrationen im Worker (Scoring, CRM, E-Mail)
  6. Alerts bei 429-Spitzen und wachsenden rejected Jobs

So verbrennen Sie kein CPU und kein Provider-Geld für Requests, die das Limit schon hätte schneiden sollen.

Checkliste zur Einführung

  • [ ] Formular und Bot haben unterschiedliche Limits je Risiko
  • [ ] Globaler Circuit Breaker für ausgehende E-Mail/SMS/LLM
  • [ ] 429 und Bot-Texte sind klar, verraten aber keinen Bypass
  • [ ] Queue hat DLQ (Dead Letter) und Längen-Monitoring
  • [ ] Verdächtige Leads gehen in Quarantäne, nicht stilles Löschen
  • [ ] Rate-Limit- und Spam-Score-Logs nutzbar ohne volle PII
  • [ ] Lasttest: was passiert bei 100 RPS auf /contact

Fazit

Ein Rate Limit drosselt Frequenz, eine Warteschlange schützt Backend und Integrationsbudgets, Antispam trennt Müll von Leads. Sie wirken nur zusammen: Limit ohne Queue legt synchrone Handler lahm; Queue ohne Filter verteilt Spam im CRM; Filter ohne Limit werden unter DDoS teuer.

Wenn Sie Schutz für Formulare und Bots für Ihren Stack brauchen (Limits, Queue, Quarantäne, Monitoring) - kontaktieren Sie mich. Orientierung zu Support und Weiterentwicklung - auf der Preisseite.

Häufig gestellte Fragen

Worin unterscheidet sich Rate Limit von Antispam?

Rate Limit zählt Versuche; Antispam bewertet Inhalt und Verhalten. Das Limit stoppt Flood auch bei «sauberen» Requests; Antispam fängt seltenen, aber toxischen Spam, der noch ins Limit passt.

Brauche ich eine Queue bei wenig Leads?

Ja, wenn externe APIs, E-Mail oder LLM im Spiel sind. Selbst bei wenig Traffic bricht ein synchrones CRM-Timeout die Formular-UX. Die Queue ist im Leerlauf günstig und rettet im Spike.

Ist CAPTCHA auf jedem Formular Pflicht?

Nein. Challenge besser nach Risiko: nach Fehlerwellen, schlechter IP-Reputation oder anomalem Score. Weniger Störung für Menschen, Bots trotzdem geschnitten.

Beim Bot: Limit nach chat_id oder IP?

Beides. chat_id stoppt Flood eines Nutzers; IP/Webhook-Token schützt vor gefälschten Updates und Scanning. In Gruppen sind Limits meist strenger als in DMs.

Wohin mit Leads, die nach Spam aussehen?

In Quarantäne mit manueller Prüfung oder verzögerter Zustellung - nicht in den Papierkorb ohne Spur. Sonst verlieren Sie einen seltenen echten Lead und sehen nicht, wie Angriffsmuster sich ändern.

Begriffe in diesem Artikel

CRM — Customer Relationship Management

webhooks — HTTP callbacks when events happen — HTTP-Rückrufe bei Ereignissen

LLM — Large Language Model

PII — Personally Identifiable Information

DDoS — Distributed Denial of Service

Kontakt