beauty-bookings/docs/rate-limiting.md

Rate Limiting & E-Mail-Validierung

Das System verwendet ein mehrstufiges Sicherheitssystem, um Spam und Missbrauch des Buchungsformulars zu verhindern.

E-Mail-Validierung

Neben der Zod-Schema-Validierung wird jede E-Mail-Adresse durch die Rapid Email Validator API geprüft:

Geprüfte Kriterien

• ✅ Syntax-Validierung: Korrekte E-Mail-Format-Prüfung
• ✅ Disposable Email Detection: Wegwerf-E-Mail-Adressen werden blockiert
• ✅ MX Record Verification: Prüft, ob die Domain E-Mails empfangen kann
• ✅ Domain Verification: Validiert die Existenz der Domain
• ✅ Typo-Erkennung: Schlägt Korrekturen bei häufigen Tippfehlern vor

Datenschutz

Die verwendete API speichert keine Daten und ist GDPR/CCPA/PIPEDA-konform. Alle E-Mail-Adressen werden nur im Speicher verarbeitet und sofort verworfen.

Fallback-Verhalten

Falls die Validierungs-API nicht erreichbar ist, fällt das System auf die Zod-Validierung zurück, um die Funktionalität zu gewährleisten.

---

Rate Limiting

Das System verwendet ein Rate-Limiting, um Spam und Missbrauch des Buchungsformulars zu verhindern.

Aktuelle Konfiguration

Buchungen (E-Mail-basiert)

• Limit: 3 Buchungsanfragen pro E-Mail-Adresse
• Zeitfenster: 1 Stunde
• Verhalten: Nach 3 Anfragen muss der Nutzer 1 Stunde warten

Buchungen (IP-basiert)

• Limit: 5 Buchungsanfragen pro IP-Adresse
• Zeitfenster: 10 Minuten
• Verhalten: Nach 5 Anfragen muss der Nutzer 10 Minuten warten

Login (IP-basiert)

• Limit: 5 fehlgeschlagene Login-Versuche pro IP-Adresse
• Zeitfenster: 15 Minuten
• Verhalten: Das Limit zählt nur fehlgeschlagene Versuche. Nach erfolgreichem Login wird der Zähler zurückgesetzt. Bei Überschreitung muss der Nutzer 15 Minuten warten.
• Zweck: Schutz vor Brute-Force-Angriffen auf Admin-Accounts

Admin-Operationen (Benutzer-basiert)

• Limit: 30 Anfragen pro Admin-Benutzer
• Zeitfenster: 5 Minuten
• Verhalten: Nach 30 Anfragen muss der Admin 5 Minuten warten
• Zweck: Verhindert versehentliches Spam durch Admin-UI (z.B. Doppelklicks, fehlerhafte Skripte)
• Betroffene Endpoints: Treatments (create/update/remove), Bookings (manualCreate/updateStatus/remove), Recurring Availability (alle Schreiboperationen), Gallery (alle Schreiboperationen), Reviews (approve/reject/delete)

Admin-Operationen (IP-basiert)

• Limit: 50 Anfragen pro IP-Adresse
• Zeitfenster: 5 Minuten
• Verhalten: Nach 50 Anfragen muss 5 Minuten gewartet werden
• Zweck: Zusätzlicher Schutz gegen IP-basierte Angriffe auf Admin-Endpoints

Wie es funktioniert

Das Rate-Limiting prüft die passenden Kriterien je Endpoint. Für Admin-Operationen werden beide Limits geprüft:

1. E-Mail-Adresse: Verhindert, dass dieselbe Person mit derselben E-Mail zu viele Anfragen stellt
2. IP-Adresse: Verhindert, dass jemand mit verschiedenen E-Mail-Adressen von derselben IP aus spammt
3. Benutzer-basiert (Admin): Limitiert Anfragen je Admin-Benutzer
4. IP-basiert (Admin): Limitiert Anfragen je IP zusätzlich

Wenn eines der Limits überschritten wird, erhält der Nutzer eine Fehlermeldung mit Angabe der Wartezeit.

IP-Erkennung

Das System erkennt die Client-IP auch hinter Proxies und Load Balancern durch folgende Headers (unterstützt Headers-API und einfache Record-Objekte):

• x-forwarded-for
• x-real-ip
• cf-connecting-ip (Cloudflare)

Implementierung

• Speicherung: In-Memory (Map)
• Cleanup: Automatisches Aufräumen alter Einträge alle 10 Minuten
• Skalierung: Für Produktionsumgebungen mit mehreren Server-Instanzen sollte Redis o.ä. verwendet werden

Anpassung

Die Limits können in src/server/lib/rate-limiter.ts angepasst werden. Beispiele:

// E-Mail-Limit anpassen
const emailConfig: RateLimitConfig = {
  maxRequests: 3,           // Anzahl der Anfragen
  windowMs: 60 * 60 * 1000, // Zeitfenster in Millisekunden
};

// IP-Limit anpassen
const ipConfig: RateLimitConfig = {
  maxRequests: 5,            // Anzahl der Anfragen
  windowMs: 10 * 60 * 1000,  // Zeitfenster in Millisekunden
};

// Login-Bruteforce-Schutz
const loginConfig: RateLimitConfig = {
  maxRequests: 5,
  windowMs: 15 * 60 * 1000,
};

// Admin-Operationen
const adminUserConfig: RateLimitConfig = {
  maxRequests: 30,
  windowMs: 5 * 60 * 1000,
};

const adminIpConfig: RateLimitConfig = {
  maxRequests: 50,
  windowMs: 5 * 60 * 1000,
};

Fehlermeldungen

Bei Überschreitung des Limits erhält der Nutzer folgende Meldung:

Zu viele Buchungsanfragen. Bitte versuche es in X Minuten erneut.

Produktions-Empfehlungen

Für Produktionsumgebungen empfehlen sich:

• ✅ Redis als verteilter Speicher für Rate-Limit-Daten
• ✅ Überwachung der Rate-Limit-Trigger (Logging/Monitoring)
• ✅ Whitelist für vertrauenswürdige IPs (z.B. Admin-Zugang)
• ✅ Anpassung der Limits basierend auf tatsächlichem Nutzungsverhalten

Siehe auch docs/redis-migration.md für Hinweise zur Migration auf Redis in Multi-Instance-Setups.