# 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](https://rapid-email-verifier.fly.dev/) 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 ## Wie es funktioniert Das Rate-Limiting prüft **beide** Kriterien: 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 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: - `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` in der Funktion `checkBookingRateLimit()` angepasst werden: ```typescript // 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 }; ``` ## 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