Content-Security-Policy (CSP)
Die Content-Security-Policy ist ein HTTP-Header, mit dem ein Server dem Browser verbindlich vorgibt, aus welchen Quellen Skripte, Stile, Bilder und weitere Ressourcen geladen werden dürfen – alles nicht ausdrücklich Erlaubte wird blockiert.
Die Content-Security-Policy ist der wirksamste einzelne Security-Header und die zentrale Browser-seitige Abwehr gegen Cross-Site-Scripting.
In einfachen Worten
Eine Content-Security-Policy arbeitet nach dem Erlaubnis-Prinzip: Der Server schickt dem Browser eine Liste zulässiger Quellen, und der Browser führt nur aus, was auf dieser Liste steht. Die Regeln sind nach Ressourcen-Art getrennt – script-src steuert Skript-Quellen, style-src die Stile, img-src die Bilder, connect-src die Verbindungen für Datenabrufe, und frame-ancestors regelt, wer die Seite in einen Rahmen einbetten darf (Schutz vor Clickjacking). Für eigene Inline-Skripte gibt es zwei Wege, sie zu erlauben, ohne pauschal alles freizugeben: einen pro Aufruf neu erzeugten Zufallswert (Nonce) bei dynamisch gerenderten Seiten oder einen festen Inhalts-Hash bei statisch ausgelieferten Seiten. Eingeführt wird eine Policy risikoarm zuerst im Report-Only-Modus: Sie meldet Verstöße, blockiert aber nichts – so lassen sich Fehl-Alarme finden, bevor scharf gestellt wird.
Wozu brauche ich das?
Sinnvoll für jede produktive Website, besonders sobald Drittanbieter-Skripte im Spiel sind – ein Verwaltungssystem für Marketing-Tags, eine Webanalyse-Lösung oder eingebettete Inhalte. Genau hier verhindert eine Policy, dass unbemerkt fremder oder manipulierter Code ausgeführt wird. Sicherheits-Audits und Penetrations-Tests prüfen die Content-Security-Policy als Standard-Element; sie fehlt auf vielen Mittelstands-Websites vollständig. Zusammen mit einer Auslieferung über HTTPS bildet sie das Grundgerüst eines sauberen Sicherheits-Profils.
Beispiel aus der Praxis
Eine Website führt die Policy zunächst im Report-Only-Modus ein und beobachtet die gemeldeten Verstöße. Dabei zeigt sich, dass über ein eingebundenes Werbe-Tag automatisch ein zusätzliches Aufzeichnungs-Werkzeug nachgeladen wird, das gar nicht erwünscht war. Nach dem Scharf-Stellen blockiert die Policy genau diese Fremd-Quelle, während die gewollten Dienste weiterlaufen – ein Befund, der ohne die Policy unsichtbar geblieben wäre. Der Aufwand bleibt überschaubar, weil die Hash-Liste der eigenen Skripte beim Bauen der Seite automatisch erzeugt wird.
Wirtschaftlicher Nutzen
Eine Content-Security-Policy kostet keine Lizenz, nur einmalige Einrichtung und etwas Pflege. Ihr Wert liegt in der zusätzlichen Schutz-Schicht gegen Cross-Site-Scripting, in der Kontrolle darüber, welcher Drittanbieter-Code im Browser der Besucher überhaupt laufen darf, und in besseren Bewertungen bei Sicherheits- und Datenschutz-Audits. Für eine Marke, die sich über Sorgfalt und Sicherheit positioniert, gehört ein vollständiges Header-Profil zur Glaubwürdigkeit. Wie ein erzwungenes HSTS gehört die Policy zum erwarteten Standard eines gepflegten Auftritts.
Typische Fehler
- Die Policy zu streng konfiguriert und scharf gestellt, ohne vorher Report-Only zu nutzen – eigene Funktionen brechen über Nacht.
- Mit „unsafe-inline" pauschal alle Inline-Skripte erlaubt – das hebt den wichtigsten Schutz wieder auf.
- Die Policy nur als Meta-Tag statt als echten HTTP-Header gesetzt – Direktiven wie frame-ancestors wirken dann nicht.
- Nach dem Einbinden neuer Drittanbieter-Werkzeuge die Policy nicht angepasst – die neuen Skripte werden blockiert oder die Lücke bleibt offen.
- Bei statischen Seiten einen Nonce einsetzen zu wollen, der pro Aufruf neu sein müsste – das funktioniert nur bei dynamischem Rendering.
Worauf achten?
- Immer zuerst im Report-Only-Modus betreiben und die Verstoß-Meldungen auswerten, bevor scharf gestellt wird.
- Inline-Skripte über Hash (statische Seiten) oder Nonce (dynamische Seiten) erlauben, nicht über „unsafe-inline".
- Die Quell-Liste so eng wie möglich halten – jede zusätzlich erlaubte Domain vergrößert die Angriffs-Fläche.
- Nach jeder Änderung am Tag-Management oder an externen Diensten die Policy gegenprüfen.
- Zum Absichern von Drittanbieter-Skripten die Policy mit Subresource Integrity kombinieren.
Häufig gestellte Fragen
Was ist eine Content-Security-Policy?
Ein HTTP-Header, der dem Browser eine Liste erlaubter Quellen für Skripte, Stile, Bilder und Verbindungen vorgibt. Alles, was nicht ausdrücklich erlaubt ist, wird blockiert – das ist die wirksamste Browser-seitige Maßnahme gegen Cross-Site-Scripting.
Was ist der Unterschied zwischen Hash und Nonce?
Beide erlauben eigene Inline-Skripte, ohne pauschal alles freizugeben. Ein Nonce ist ein pro Seitenaufruf neu erzeugter Zufallswert und passt zu dynamisch gerenderten Seiten; ein Hash prüft den festen Inhalt eines Skripts und passt zu statisch ausgelieferten Seiten.
Was bedeutet Report-Only?
Ein Modus, in dem die Policy aktiv ist, Verstöße aber nur meldet statt sie zu blockieren. So lassen sich Fehl-Alarme erkennen und beheben, bevor die Policy scharf gestellt wird – die Seite läuft währenddessen unverändert.
Bremst eine CSP die Website aus?
Nein. Der Header ist nur wenig zusätzlicher Text in der Server-Antwort und kostet keine messbare Ladezeit. Auch Tracking- und Marketing-Tools laufen weiter, sofern ihre Quellen in der Policy freigegeben sind.