Files

elpatron 8ee2a2b3b6 feat: ICS-Kalendereinträge, Rate-Limiting und erweiterte E-Mail-Validierung

- ICS-Dateianhänge in Bestätigungsmails mit Europe/Berlin Zeitzone
- Rate-Limiting: IP-basiert (5/10min) und E-Mail-basiert (3/1h)
- Mehrschichtige E-Mail-Validierung mit Rapid Email Validator API
  - Disposable Email Detection (blockiert Wegwerf-Adressen)
  - MX Record Verification
  - Domain Verification
  - Typo-Erkennung mit Vorschlägen
- Zod-Schema-Validierung für Name, E-Mail und Telefonnummer
- Dokumentation für Rate-Limiting und E-Mail-Validierung
- README mit neuen Features aktualisiert
- Backlog aktualisiert

2025-10-01 11:43:51 +02:00

3.3 KiB

Raw Permalink Blame History

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

Wie es funktioniert

Das Rate-Limiting prüft beide Kriterien:

E-Mail-Adresse: Verhindert, dass dieselbe Person mit derselben E-Mail zu viele Anfragen stellt
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:

// 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

3.3 KiB Raw Permalink Blame History