Content Security Policy (CSP)

Was eine Richtlinie tatsächlich steuert

Eine Richtlinie ist eine Liste von Direktiven, von denen jede eine Art von Anfrage regelt. Sie wurde als zweite Verteidigungslinie gegen Cross-Site-Scripting entworfen: Gelingt es einem Angreifer, Markup in deine Seite einzuschleusen, verweigert der Browser trotzdem Skripte aus einer Quelle, die die Richtlinie nie genannt hat. Die Direktiven, denen du zuerst begegnest:

• default-src — der Rückfallwert. Jeder Abruftyp ohne eigene Direktive erbt diese, also deckt default-src 'self' stillschweigend auch Schriften, Medien und mehr ab, sofern du nichts anderes festlegst.
• script-src, style-src, img-src, font-src — woher die jeweilige Art von Unterressource stammen darf. 'self' steht für den eigenen Ursprung der Seite; ein Hostname erlaubt diesen Host; 'unsafe-inline' erlaubt Code, der direkt in der Seite steht.
• connect-src — wohin der eigene Code der Seite Anfragen per fetch, XHR oder WebSockets schicken darf. Diese Direktive entscheidet, ob ein Skript nach Hause telefonieren kann.
• form-action — wohin ein Formular gesendet werden darf. frame-ancestors — wer die Seite in einem Frame einbetten darf, der moderne Ersatz für X-Frame-Options.
• Nonces und Hashes — eine Möglichkeit, genau ein bestimmtes Inline-Skript zu erlauben, ohne alle zu erlauben: Der Server markiert das Skript, das er selbst geschrieben hat, und allem, was später eingeschleust wird, fehlt diese Markierung.

Zwei Details bei der Auslieferung bringen Leute regelmäßig ins Stolpern. Eine Richtlinie lässt sich auch in einem <meta http-equiv>-Tag setzen, doch diese Form unterstützt nicht alle Funktionen, und eine reine Report-Richtlinie lässt sich so überhaupt nicht ausliefern. Und wenn eine Richtlinie dieselbe Direktive zweimal enthält, befolgt der Browser die erste und ignoriert die zweite — eine „hinzugefügte“ Regel kann also nichts bewirken und im Quelltext trotzdem korrekt aussehen.

Warum eine blockierte Ressource lautlos scheitert

Verweigert der Browser eine Anfrage aufgrund einer Richtlinie, schreibt er eine Zeile in die Entwicklerkonsole und rendert einfach weiter. Keine Fehlerseite, kein Hinweis, nichts, was einem Besucher oder einem Betreiber bei einem kurzen Blick auf die Website auffallen würde. Wie die Seite danach aussieht, hängt ganz davon ab, was verweigert wurde. Ein blockiertes Analyse-Skript lässt die Seite pixelgenau gleich aussehen und deine Zahlen bei null. Eine blockierte Webschrift fällt auf eine Systemschrift zurück, die den meisten gar nicht auffällt. Ein blockiertes Stylesheet oder CSS-Framework verwandelt eine gestaltete Seite in ungestyltes Standard-HTML.

Genau diese Spannbreite ist das praktische Problem: Dieselbe Art von Verstoß reicht von unsichtbar bis seitenzerstörend, und der Text der Richtlinie verrät dir nicht, an welchem Ende du stehst. Teste die veröffentlichte URL, nicht eine lokale Kopie — eine Datei, die du auf deinem Laptop öffnest, wird meist ganz ohne Richtlinie ausgeliefert und kann daher alles laden, was die Live-Seite verweigern wird. Das ist der häufigste Grund, warum eine mit KI gebaute Seite in der Vorschau richtig aussieht und nach der Veröffentlichung falsch.

Was uns der Betrieb für fremde Seiten gelehrt hat

AgentCeres — der AI Growth Officer auf agentceres.com — veröffentlicht die Seiten, die seine Agents für Kunden bauen, und jede davon wird unter einer strengen Richtlinie ausgeliefert: Ressourcen nur vom eigenen Ursprung der Seite, Bilder vom Ursprung oder direkt eingebettet, Formulare, die nur zurück an den Host senden, keine Einbettung in andere Websites und connect-src 'none'. Code auf der Seite kann also rechnen, sich lokal etwas merken und navigieren, aber keine einzige Netzwerkanfrage stellen. Diese letzte Regel ist der Grund, warum sich ein Geheimnis, das im Seitencode steht, von der Live-Seite aus nicht einmal verwenden lässt.

Als wir am 2026-09-04 jede gehostete Seite geprüft haben, enthielten 5 von 52 mindestens eine externe Ressource, die nie geladen wurde. Der schlimmste Fall war eine Seite, deren gesamtes Layout aus einem CSS-Framework von einem öffentlichen CDN kam; die Richtlinie nennt keinen externen Host, also kam das Framework nie an, und die Seite ging als schlichter, ungestylter Text live. Andere verloren einen Radio-Stream oder einen eingebetteten Frame. Wir haben überlegt, blockierte Verweise beim Veröffentlichen zu entfernen, und das verworfen, denn eine bereinigte Seite „veröffentlicht sich problemlos“ und sieht trotzdem falsch aus. Die Veröffentlichung ganz zu verweigern war nicht besser, denn dieselbe Regel würde eine Seite wegen einer Schrift blockieren, die lediglich auf eine Ersatzschrift zurückfällt. Deshalb meldet der Veröffentlichungsschritt jeden blockierten Verweis zusammen mit der Direktive, die ihn verweigern wird, und die Korrektur passiert, bevor irgendwer die Seite sieht. Das Urteil wird aus derselben Direktivenliste berechnet, die der Server ausliefert, Rückfallwerte eingeschlossen — die Warnung kann also nicht von der Richtlinie abweichen.

Die Lehre gilt weit über unser Setup hinaus: Eine Richtlinie, die du nicht an echten Seiten überprüfst, ist eine Richtlinie, die Seiten kaputt macht, ohne es dir zu sagen. Bevor du eine durchsetzt, schick sie als Content-Security-Policy-Report-Only, das Verstöße meldet, ohne etwas zu blockieren, und lies nach, was sie kaputt gemacht hätte.

Was eine Richtlinie nicht kann

CSP regelt, was eine Seite laden und wohin sie sich verbinden darf. Man schreibt ihr leicht mehr zu als das.

• Sie hat keine Direktive für Cookies. Ein Skript, das die Richtlinie zulässt, kann weiterhin Cookies lesen und setzen, ausgenommen solche mit HttpOnly-Markierung. Seiten unter derselben übergeordneten Domain können sich auch Cookies teilen, und das zu unterbinden erfordert eine eigene Maßnahme, keine strengere Richtlinie.
• Sie macht Inline-Code nicht sicher. Wer 'unsafe-inline' erlaubt, lässt alles zu, was in der Seite steht, auch das, was ein Angreifer dort hineingeschrieben hat; genau dafür gibt es Nonces und Hashes.
• Sie ersetzt kein Escaping und keine Validierung. Sie begrenzt den Schaden einer Injection, verhindert sie aber nicht. Eine Seite, die Nutzereingaben vertraut, ist weiterhin kaputt, nur schwerer auszunutzen.
• Sie schützt einen KI-Agent nicht vor seinen Eingaben. Eine Richtlinie hält einen Browser davon ab, ein feindliches Skript zu laden; gegen feindlichen *Text*, den ein Agent liest und nach dem er handelt, bewirkt sie nichts — das ist das separate Problem der Prompt-Injection.