EMZETT.Content Security Policy (CSP)
Kurz: Ein HTTP-Header, mit dem eine Website dem Browser genau vorschreibt, woher Skripte, Bilder, Styles und andere Inhalte geladen werden dürfen — alles andere blockiert der Browser.
Genauer: Die Policy besteht aus Regeln („Direktiven“) wie script-src (erlaubte Skriptquellen), img-src, connect-src (erlaubte Verbindungen per fetch) und frame-ancestors (wer die Seite einbetten darf). Sie wirkt als zweite Verteidigungslinie gegen XSS: Selbst wenn ein Angreifer HTML einschleusen kann, führt der Browser fremde Skripte nicht aus, wenn die Policy sie verbietet.
Kontext bei uns: Emzett setzt eine CSP in next.config.ts, zusammen mit HSTS, X-Frame-Options: DENY und nosniff. Das Wiki hat eine eigene CSP ohne CDN-Quellen — alle Skripte liegen auf unserer eigenen Domain. Ehrlich gesagt erlaubt unsere Policy für Skripte noch 'unsafe-inline', weil Next.js Inline-Skripte erzeugt; die strengere Variante mit Nonces steht auf der Verbesserungsliste.
Im Detail
Typische Direktiven
default-src 'self': Grundregel, nur eigene Domain.script-src: erlaubte Skripte;'unsafe-inline'und'unsafe-eval'schwächen den Schutz stark.frame-ancestors 'none': niemand darf die Seite in einem iframe einbetten (Schutz vor Clickjacking).connect-src: erlaubte Ziele für API-Aufrufe (bei uns z. B. Pusher für den Echtzeit-Chat und Stripe).
Aufwand und Fallen
Frameworks erzeugen inline Skripte (bei Next.js z. B. für Hydration), die eine strenge Policy blockieren würde; sauber löst man das mit Nonces oder Hashes. Jeder neue Drittanbieter (Analytics, Videos) muss in die Policy eingetragen werden — das ist gewollt, denn so fällt jede neue Datenverbindung bewusst auf. Ein Testlauf mit Content-Security-Policy-Report-Only zeigt Verstöße, ohne etwas zu blockieren.