Security Headers für Cloudflare Pages und React-Websites
Wie Security Headers, kanonische Metadaten und Response-Verifikation typische browserseitige Risiken auf statischen React-Deployments reduzieren.
Kernpunkte
- Security Headers sollten als Deployment-Konfiguration behandelt werden, nicht als bloße Code-Kommentare.
- Cloudflare Pages unterstützt statische Header-Regeln, die vor Release getestet werden können.
- Wildcard-CORS ist für öffentliche statische Antworten meist zu breit, wenn es keinen konkreten Cross-Origin-Anwendungsfall gibt.
Das Basis-Header-Set
Eine gehärtete React-Site sollte Browserverhalten explizit setzen. Die genaue Policy hängt von der Anwendung ab, enthält aber meist Content-Type-Schutz, Clickjacking-Schutz, Referrer-Kontrolle, Permissions Policy und eine bewusst gewählte Content Security Policy.
Bei statischen Hosts wird das leicht vergessen, weil die App auch ohne Header rendert. Die Sicherheitsarbeit muss auf der HTTP-Response-Ebene verifiziert werden.
Cloudflare-Pages-Besonderheiten
- Halten Sie Header-Regeln möglichst nah am Repository, damit Änderungen mit Code reviewed werden.
- Vermeiden Sie reine Dashboard-Änderungen ohne Dokumentation, weil sie später schwerer zu auditieren sind.
- Prüfen Sie www und Apex-Domain, wenn beide ausgeliefert werden.
- Kontrollieren Sie, dass Redirects wichtige Header aus der finalen Response nicht entfernen.
CORS braucht Absicht
Access-Control-Allow-Origin: * wird oft ohne Grund in Websites kopiert. Für normale Webseiten hilft breites CORS Besuchern meist nicht und kann unbeabsichtigte Datenexposition erleichtern, wenn später Endpunkte unter derselben Policy ergänzt werden.
Was automatisiert werden sollte
- Ein Test, der Wildcard-CORS in der statischen Header-Konfiguration ablehnt.
- Ein Build-Schritt, der Sitemap- und Robots-Dateien veröffentlicht.
- Ein Preview-Check, der Rendering kritischer Seiten und vorhandene Metadaten bestätigt.
- Ein Live-Response-Check nach dem Deployment für Produktionsdomains.