Die Content Security Policy (CSP) ist ein Sicherheitsmechanismus, mit dem eine Website dem Browser über einen HTTP-Header mitteilt, aus welchen Quellen Skripte, Styles, Bilder und andere Ressourcen geladen werden dürfen. Sie erschwert insbesondere Cross-Site-Scripting-Angriffe (XSS) und das Einschleusen fremder Inhalte.
Eine CSP ist wie eine Gästeliste am Eingang Ihrer Website: Der Browser lässt nur Inhalte herein, die ausdrücklich darauf stehen. Versucht ein Angreifer, fremden Code einzuschleusen, wird dieser in der Regel schon an der Tür abgewiesen.
Wozu brauche ich eine Content Security Policy?
Cross-Site-Scripting (XSS) gehört seit Jahren zu den verbreitetsten Angriffsarten auf Websites: Angreifer schleusen fremden JavaScript-Code ein, der im Browser der Besucher ausgeführt wird – etwa um Formulareingaben oder Zahlungsdaten abzugreifen. Eine Content Security Policy bildet dagegen eine zweite Verteidigungslinie: Selbst wenn Schadcode auf die Seite gelangt, kann der Browser dessen Ausführung verhindern, weil die Quelle nicht in der Richtlinie freigegeben ist.
Technisch wird die CSP als HTTP-Header ausgeliefert und besteht aus Direktiven wie script-src, style-src oder img-src, die je Ressourcen-Typ die erlaubten Quellen definieren. Moderne Richtlinien arbeiten mit Nonces oder Hashes, um einzelne Inline-Skripte gezielt freizugeben, statt Inline-Code pauschal zu erlauben. Browser unterstützen den Mechanismus seit vielen Jahren flächendeckend; die Einführung scheitert in der Praxis selten an der Technik, sondern am fehlenden Überblick darüber, welche Quellen eine gewachsene Website tatsächlich nutzt. Eine Bestandsaufnahme aller eingebundenen Dienste ist deshalb der sinnvolle erste Schritt.
Praxis-Relevanz für Shop- und Website-Betreiber
Online-Shops binden typischerweise viele Drittquellen ein: Payment-Anbieter, Analytics, Tag-Manager, Schriften, Chat-Widgets. Genau diese Vielfalt macht sie zum Ziel von Angriffen wie Web-Skimming, bei denen manipulierte Drittskripte Kartendaten im Checkout abgreifen. Eine sauber gepflegte CSP kann solche Risiken deutlich begrenzen und ist ein Baustein einer mehrschichtigen Sicherheitsstrategie, wie wir sie im Beitrag IT-Sicherheit im E-Commerce beschreiben. Auch Zero-Trust-Ansätze folgen demselben Grundgedanken: keiner Quelle pauschal vertrauen.
Typische Fehler
- unsafe-inline als Dauerlösung: Wer Inline-Skripte pauschal erlaubt, schwächt den XSS-Schutz erheblich – Nonces oder Hashes sind der sauberere Weg.
- CSP ohne Testphase scharf schalten: Eine zu strikte Richtlinie blockiert schnell Payment- oder Tracking-Skripte; der Report-Only-Modus meldet Verstöße zunächst nur, ohne zu blockieren.
- Drittanbieter-Änderungen ignorieren: Externe Dienste ändern gelegentlich ihre Domains – ohne laufende Pflege bricht dann unbemerkt Funktionalität weg.
- Zu großzügige Wildcards: Sehr breite Freigaben erlauben faktisch beliebige Quellen und entwerten die Richtlinie weitgehend.
Worauf Sie achten sollten
Führen Sie eine CSP schrittweise ein: zunächst im Report-Only-Modus mit Auswertung der gemeldeten Verstöße, anschließend sukzessive verschärfen. Jede freigegebene Quelle sollte begründbar sein; Inline-Code wird idealerweise über Nonces oder Hashes legitimiert. Änderungen am Header testen Sie am besten auf einer Staging-Umgebung, bevor sie live gehen – ein fehlerhafter Eintrag kann sonst den Checkout lahmlegen. Bei der Konfiguration von Sicherheits-Headern unterstützen wir Sie im Rahmen von Hosting & Wartung und individueller Entwicklung.
Eine Content Security Policy ergänzt sichere Programmierung, Updates und weitere Security-Header (etwa HSTS und X-Content-Type-Options) – sie ersetzt diese Maßnahmen nicht. Bei Managed Hosting gehört die Header-Pflege idealerweise zum Betriebskonzept.