CSP FÜR STATISCHE WEBSITES

Content Security Policy ist ein HTTP-Header, der dem Browser mitteilt, welche Origins Ressourcen für deine Seite laden dürfen. Richtig gemacht, verhindert es die meisten XSS-, Clickjacking- und Supply-Chain-Angriffe. Falsch gemacht, deaktiviert es Funktionen stillschweigend auf Wegen, deren Diagnose Tage dauert.

Statische Websites dokumentieren ihre CSP tendenziell unzureichend, weil das wahrgenommene Risiko niedriger ist. Die Realität ist, dass eine statische Website mit einer fehlenden CSP-Direktive die Videowiedergabe, das Laden von Bildern, die Suchfunktionalität oder die Font-Darstellung unterbrechen kann, und die Browser-Konsolenmeldung ist das einzige Signal, das du erhältst.

Die Direktive, die jeden Ressourcentyp steuert:

img-src für img-Tags. media-src für video-, audio- und source-Elemente. frame-src für iframe. connect-src für fetch und WebSocket. script-src für script-Tags. style-src für style-Tags und link rel=stylesheet. font-src für @font-face.

Kritisch: default-src "self" deckt NICHT video von einem Third-Party-Host ab. Ein Video von Supabase Storage wird stillschweigend nicht abgespielt, wenn nur das Poster sichtbar ist, falls du media-src vergisst. Die Browser-Konsole zeigt die Direktive, die es blockiert hat; schau dort zuerst nach, wenn das Video mysteriös nicht abgespielt wird.

Auf gautamkhorana.com im Mai 2026 renderte ein Kling-MP4, gehostet auf Supabase Storage, das HTML korrekt, spielte aber nie ab. Das Poster-Bild wurde angezeigt; das Video würde nicht starten. Nach zwanzig Minuten Debugging war die Antwort, dass die CSP keine media-src-Direktive hatte und der Browser das video-Element stillschweigend blockierte.

Die Lösung war eine einzeilige Ergänzung zu netlify.toml: media-src "self" https://*.supabase.co. Das Symptom Poster-aber-keine-Wiedergabe ist das charakteristische Muster: es bedeutet, dass CSP das Bild erlaubt, aber nicht das Video.

Pagefind, Stork, Tinysearch und andere Static-Site-Such-Bibliotheken verwenden WebAssembly plus Web Workers. CSP muss script-src "wasm-unsafe-eval" UND worker-src "self" blob: enthalten, sonst hängt die Suche ewig bei "Searching..." fest, ohne Fehler in der Konsole.

Zweiter Incident auf gautamkhorana.com im Mai 2026: Such-Schublade steckte bei "Searching..." fest, weil pagefind.init() stillschweigend fehlschlug, als wasm blockiert wurde. Die Lösung bestand darin, "wasm-unsafe-eval" zu script-src und "self" blob: zu worker-src hinzuzufügen.

Erforderlich:

img-src self https://*.supabase.co https://*.fal.media, für Hero-Images und FAL-generierte Assets. media-src self https://*.supabase.co, für Videos. connect-src self https://*.supabase.co, für Supabase-API-Aufrufe. script-src self "wasm-unsafe-eval", für Pagefind. worker-src self blob:, für Pagefind-Worker. style-src self "unsafe-inline", für Astro-Scoped-Styles. font-src self, für selbst gehostete Schriftarten.

Immer wenn du einen neuen Asset-Host hinzufügst (Cloudinary, Bunny, R2, was auch immer), überprüfe netlify.toml oder vercel.json und füge den Host zu jeder Direktive hinzu, die dieser Ressourcentyp nutzen könnte. Die Kosten für einen Fehler hier sind ein stilles Fehlschlagen, das erst in der Produktion auftaucht.

CSP-Report-Only-Modus lässt dich Richtlinienänderungen in der Produktion testen, ohne etwas zu zerstören. Der Browser protokolliert Verstöße, die abgelehnt würden, an einen Reporting-Endpoint statt die Anfrage zu blockieren. Führe jede neue Direktive eine Woche lang im Report-Only-Modus aus, überprüfe die Verstöße und aktiviere dann die Durchsetzung.

Die meisten CSP-Fehler sind in der Produktion unmerklich. Ein Reporting-Endpoint ist die einzige Möglichkeit, um zu wissen, was du tatsächlich zerstört hast. Richte einen auf, bevor du eine nicht triviale CSP-Änderung auslieferst.