# 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

### 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:

```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
};

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