134 lines
5.0 KiB
Markdown
134 lines
5.0 KiB
Markdown
# 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.
|
|
|