CSP-System

Die CSP selbst ist ein Sicherheitsmechanismus des Browsers, der über zulässige Quellen und bestimmte Ausführungswege für Ressourcen einer Website oder Webanwendung entscheidet.

Eine Content Security Policy kann unter anderem steuern, von welchen Ursprüngen Skripte, Stylesheets, Bilder, Schriftarten, Medien, Frames oder API-Verbindungen geladen werden dürfen. Sie kontrolliert jedoch nicht sämtliche Browseraktivitäten: Navigationen zu anderen Websites, Downloads, serverseitige Datenflüsse oder die Sicherheit einer erlaubten Quelle werden nicht umfassend durch CSP geregelt. Eine freigegebene Ressource kann beispielsweise weiterhin kompromittiert sein oder unsicheren Code ausliefern.

Besonders relevant ist CSP als zusätzliche Schutzschicht gegen Cross-Site-Scripting, kurz XSS. XSS-Schwachstellen ermöglichen es Angreifern, JavaScript in Webseiten oder Anwendungen einzuschleusen, etwa über Formulare, Kommentare, Produktdaten oder manipulierte URLs. Eine sorgfältig konfigurierte CSP kann solche Angriffe erheblich erschweren, bietet jedoch keinen vollständigen Schutz gegen alle XSS-Varianten, insbesondere nicht bei zu breiten Freigaben, kompromittierten Drittanbieter-Skripten oder unsicher implementierten Nonces.

Für Unternehmen mit Informationsmanagementsystemen ist CSP vor allem dann wichtig, wenn Inhalte aus CMS-, PIM-, DAM-, ERP- oder CRM-Systemen über Webportale, Produktkataloge oder Kundenbereiche bereitgestellt werden. Sie hilft dabei, die im Browser zulässigen technischen Abhängigkeiten nachvollziehbar zu begrenzen. Die Richtlinie ersetzt aber weder eine sichere Datenpflege noch Zugriffskontrollen, Eingabevalidierung oder die Absicherung von Schnittstellen.

Was ist eine Content Security Policy?

Eine Content Security Policy ist ein Satz von Sicherheitsregeln, den ein Webserver bevorzugt über den HTTP-Header Content-Security-Policy an den Browser übermittelt. Der Browser wendet die Richtlinie beim Laden und Ausführen betroffener Ressourcen an. Verstößt eine Ressource gegen die Richtlinie, blockiert der Browser sie im Enforce-Modus grundsätzlich.

Alternativ kann eine CSP mit <meta http-equiv="Content-Security-Policy"> im HTML-Dokument definiert werden. Diese Methode ist jedoch funktional eingeschränkt und wird deshalb nicht als primärer Auslieferungsweg empfohlen. Insbesondere frame-ancestors, das die Einbettung einer Seite durch andere Websites regelt, ist über ein Meta-Element nicht wirksam und muss per HTTP-Header ausgeliefert werden.

Eine einfache CSP kann beispielsweise so aussehen:

Content-Security-Policy: default-src 'self'; script-src 'self'

'self' bedeutet dabei nicht lediglich „die eigene Domain“, sondern denselben Origin. Ein Origin setzt sich insbesondere aus Schema, Host und Port zusammen. https://www.beispiel.de und http://www.beispiel.de sind daher ebenso unterschiedliche Origins wie https://www.beispiel.de und https://api.beispiel.de.

Die dargestellte Richtlinie erlaubt standardmäßig nur Ressourcen vom selben Origin und beschränkt JavaScript ebenfalls auf diesen Origin. Sie ist allerdings nur eine einfache Ausgangsbasis und nicht automatisch eine robuste XSS-Schutzstrategie. Anwendungen mit dynamisch geladenen Skripten, umfangreichen Frontend-Frameworks oder Drittanbieter-Diensten benötigen häufig eine differenziertere Richtlinie mit Nonces, Hashes und gegebenenfalls 'strict-dynamic'.

Warum ist ein CSP-System wichtig?

Websites, Portale und digitale Plattformen bestehen heute meist aus zahlreichen technischen Komponenten. Neben dem eigentlichen Webauftritt können Content-Management-Systeme, Analysewerkzeuge, Consent-Management-Plattformen, Zahlungsdienstleister, Kartenanbieter, Videoplayer, Schriftarten, Content Delivery Networks und externe APIs eingebunden sein. Jede dieser Abhängigkeiten kann zusätzliche Angriffs- und Fehlerquellen schaffen.

Eine CSP schafft Transparenz darüber, welche Ressourcen Ihre Anwendung im Browser tatsächlich benötigt. Sie kann das Laden nicht vorgesehener Skripte, Medien oder Netzwerkverbindungen verhindern, sofern diese nicht durch die Richtlinie erlaubt sind. Sie kontrolliert jedoch nicht, welche Daten ein bereits erlaubter Tracking-Dienst verarbeitet oder ob ein freigegebener Drittanbieter sicher arbeitet.

Typische Vorteile eines professionell gepflegten CSP-Managements sind:

• Reduzierung der Angriffsfläche für bestimmte XSS-Angriffe
• Begrenzung nicht vorgesehener Skript-, Style- und Ressourcenquellen
• Kontrolle zulässiger API-Verbindungen, Frames und Formularziele
• Transparenz über technische Abhängigkeiten im Frontend
• frühzeitiges Erkennen veralteter oder unerwarteter Einbindungen
• Unterstützung interner Sicherheitsvorgaben und Entwicklungsstandards
• bessere Nachvollziehbarkeit bei Audits, wenn Richtlinien versioniert, dokumentiert und überwacht werden
• strukturierte Prüfung neuer Drittanbieter-Dienste vor der Produktivsetzung

CSP ist besonders sinnvoll für Kundenportale, E-Commerce-Plattformen, Intranets, Self-Service-Bereiche und Anwendungen mit Login, Formularen oder geschäftskritischen Daten. Die Verwendung einer CSP ist jedoch keine eigenständige Datenschutz- oder Compliance-Maßnahme und folgt nicht automatisch aus der Verarbeitung personenbezogener Daten. Sie ist ein technischer Baustein innerhalb eines umfassenden Sicherheitskonzepts.

Wie funktioniert eine Content Security Policy?

CSP arbeitet mit Direktiven. Jede Direktive definiert Regeln für einen bestimmten Ressourcentyp oder ein bestimmtes Browserverhalten. Beim Laden einer Ressource prüft der Browser, ob deren Quelle und gegebenenfalls ihre Ausführungsart mit den Vorgaben der Richtlinie übereinstimmen.

Ist eine Ressource nicht erlaubt, blockiert der Browser sie im Enforce-Modus. Ein Verstoß wird nur dann an ein Reporting-System gemeldet, wenn Reporting ausdrücklich konfiguriert ist und der jeweilige Browser den Bericht versendet. CSP-Reports sind daher wertvolle Hinweise, aber keine lückenlose oder forensisch eindeutige Erfassung aller Sicherheitsereignisse.

Wichtige CSP-Direktiven sind unter anderem:

• default-src definiert eine Standardregel für bestimmte Fetch-Direktiven, die nicht separat gesetzt sind. Sie ersetzt jedoch nicht etwa base-uri, form-action, frame-ancestors oder sandbox.
• script-src regelt zulässige JavaScript-Quellen und Ausführungsoptionen, etwa Nonces, Hashes oder 'strict-dynamic'.
• script-src-elem kann Regeln für Skripte in <script>-Elementen präzisieren.
• script-src-attr steuert Inline-Event-Handler wie onclick oder onload.
• style-src regelt externe Stylesheets sowie Inline-Styles.
• style-src-elem kann Styles in <style>-Elementen und externe Stylesheets gesondert behandeln.
• style-src-attr steuert style-Attribute direkt in HTML-Elementen.
• img-src definiert zulässige Bildquellen, beispielsweise den eigenen Origin, ein CDN oder bei Bedarf data:-URLs.
• font-src regelt Quellen für Webfonts und Schriftdateien.
• connect-src begrenzt Verbindungen zu APIs, WebSockets, Analyseplattformen und externen Schnittstellen.
• media-src bestimmt Quellen für Audio- und Videodateien.
• frame-src legt fest, welche externen Inhalte Ihre Anwendung in Frames oder iFrames einbetten darf.
• frame-ancestors bestimmt, welche Websites Ihre Anwendung einbetten dürfen, und reduziert so Clickjacking-Risiken.
• worker-src regelt Quellen für Web Worker, Shared Worker und Service Worker.
• manifest-src bestimmt, von welchen Quellen Web-App-Manifeste geladen werden dürfen.
• object-src beschränkt Plug-in-Inhalte und sollte in modernen Anwendungen in der Regel auf 'none' gesetzt werden.
• base-uri legt fest, welche Quellen für das HTML-Element <base> zulässig sind.
• form-action begrenzt die Ziele, an die Formulare Daten senden dürfen.
• sandbox kann Dokumentfunktionen wie Skriptausführung, Formulare, Pop-ups oder Origin-Verhalten zusätzlich einschränken.

Die ältere Direktive child-src wurde in modernen Konfigurationen weitgehend durch spezifischere Direktiven wie frame-src und worker-src abgelöst. Sie kann in älteren Umgebungen noch relevant sein, sollte aber nicht die präziseren Direktiven ersetzen. Welche Direktiven sinnvoll sind, hängt von Architektur, Browserunterstützung und den tatsächlich benötigten Funktionen Ihrer Anwendung ab.

CSP ausliefern und Reporting konfigurieren

Für den wirksamen Schutz wird CSP über den Header Content-Security-Policy ausgeliefert. Der Headerwert wird in der tatsächlichen HTTP-Antwort üblicherweise als zusammenhängende Zeichenfolge ausgegeben. Mehrzeilige Darstellungen dienen in Dokumentationen nur der besseren Lesbarkeit und müssen abhängig von Server, Reverse Proxy oder Framework korrekt in einen gültigen Headerwert überführt werden.

Neben dem Enforce-Modus gibt es den Report-Only-Modus. Dieser wird mit dem Header Content-Security-Policy-Report-Only ausgeliefert und meldet mögliche Verstöße, ohne Ressourcen zu blockieren. Report-Only ist deshalb für Tests und schrittweise Einführungen hilfreich, entfaltet jedoch selbst keine Schutzwirkung.

Modernes Reporting kann über die CSP-Direktive report-to in Verbindung mit dem Header Reporting-Endpoints konfiguriert werden. Der ältere Mechanismus report-uri gilt als veraltet, kann für die Kompatibilität mit älteren Browsern jedoch ergänzend sinnvoll sein. Ein mögliches vereinfachtes Beispiel lautet:

Reporting-Endpoints: csp-endpoint="https://reports.beispiel.de/csp"
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-to csp-endpoint; report-uri /csp-report

Mit 'report-sample' können Browser in bestimmten Fällen begrenzte Ausschnitte blockierten Inline-Codes in CSP-Reports übermitteln. Diese Funktion erleichtert die Fehleranalyse, kann aber vertrauliche Inhalte oder personenbezogene Daten in Berichte aufnehmen. Sie sollten deshalb genau prüfen, welche Daten Ihr Reporting-Endpunkt speichert, wer darauf zugreifen darf und wie lange sie aufbewahrt werden.

Beispiel für eine restriktive Ausgangskonfiguration

Eine einfache, restriktive CSP für eine Webanwendung kann beispielsweise so aufgebaut sein:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests

Diese Richtlinie erlaubt Ressourcen vom selben Origin, eingeschränkt Bilder als data:-URLs und keine Plug-in-Objekte. Sie verhindert außerdem, dass andere Websites die Anwendung in einem Frame einbetten, und beschränkt Formularziele auf den eigenen Origin. Für ältere Clients kann zusätzlich der Header X-Frame-Options eingesetzt werden, obwohl frame-ancestors die modernere und flexiblere Steuerung bietet.

upgrade-insecure-requests veranlasst den Browser, betroffene unsichere Ressourcenanfragen auf HTTPS umzustellen. Die Direktive stellt jedoch nicht sicher, dass das Ziel über HTTPS erreichbar ist, und kann Ladefehler verursachen, wenn keine HTTPS-Ressource verfügbar ist. Sie ersetzt weder eine konsequente HTTPS-Konfiguration noch HTTP Strict Transport Security, kurz HSTS.

Die Direktive block-all-mixed-content war früher eine ergänzende Maßnahme gegen gemischte Inhalte. Sie ist heute meist weniger relevant, weil moderne Browser viele unsichere Inhalte bereits blockieren und eine vollständige HTTPS-Umsetzung, HSTS sowie upgrade-insecure-requests in der Praxis wichtiger sind. Ihre konkrete Wirkung und Unterstützung sollten Sie vor einem Einsatz anhand Ihrer Zielbrowser prüfen.

In vielen Anwendungen sind zusätzliche, eng eingegrenzte Freigaben erforderlich. Ein CDN für Produktbilder oder ein externer API-Endpunkt kann beispielsweise gezielt aufgenommen werden:

Content-Security-Policy: default-src 'self'; img-src 'self' https://media.beispiel.de; connect-src 'self' https://api.beispiel.de; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'

Freigaben wie * oder https: sollten Sie kritisch prüfen. https: erlaubt grundsätzlich Ressourcen von jeder per HTTPS erreichbaren Quelle innerhalb der jeweiligen Direktive, was bei Skripten besonders riskant sein kann. Das konkrete Risiko hängt aber von der gesamten Richtlinie, der Anwendungsarchitektur und den eingebundenen Diensten ab.

Nonces, Hashes und strict-dynamic

Eine strenge CSP blockiert Inline-JavaScript und Inline-CSS standardmäßig. Das ist sinnvoll, weil gerade Inline-Code bei XSS-Angriffen missbraucht werden kann. Wenn Ihre Anwendung technisch auf bestimmte Inline-Skripte oder <style>-Blöcke angewiesen ist, sind Nonces und Hashes sicherere Alternativen zu einer pauschalen Freigabe über 'unsafe-inline'.

Ein Nonce ist ein kryptografisch zufällig erzeugter Wert, der für jede einzelne HTTP-Antwort neu erstellt werden muss. Derselbe Wert muss im CSP-Header und im zugehörigen <script>- oder <style>-Element stehen. Nonces dürfen weder vorhersehbar noch wiederverwendet sein und sollten nicht durch fehlerhafte Caching-Konfigurationen an viele Nutzer mit demselben Wert ausgeliefert werden.

Ein Beispiel für eine noncebasierte Richtlinie lautet:

Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mB64WertMitAusreichenderLaenge=' 'strict-dynamic'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'

Der zugehörige Wert wird im HTML-Dokument verwendet:

<script nonce="r4nd0mB64WertMitAusreichenderLaenge=">
 // bewusst freigegebener JavaScript-Code
</script>

'strict-dynamic' kann bei nonce- oder hashbasierten Skriptrichtlinien sinnvoll sein. Es ermöglicht modernen Browsern, dynamisch nachgeladene Skripte als vertrauenswürdig zu behandeln, wenn sie durch ein bereits mittels Nonce oder Hash autorisiertes Skript geladen werden. Diese Funktion sollte nur eingesetzt werden, wenn die freigegebenen Startskripte selbst sorgfältig geprüft und geschützt sind.

Ein Hash eignet sich besonders für unveränderliche Inline-Skripte oder <style>-Blöcke. Der Hashwert wird aus dem exakten Inhalt gebildet und in der CSP hinterlegt. Schon kleinste Änderungen am Inhalt führen zu einem anderen Hash, sodass der Browser den geänderten Code blockiert, bis die Richtlinie angepasst wurde.

Content-Security-Policy: script-src 'self' 'sha256-BeispielhashDerAusDemExaktenSkriptinhaltEntsteht='

Nonces und Hashes geben nicht beliebige style-Attribute oder Event-Handler frei. Für Event-Handler und bestimmte Attributfälle wären zusätzliche Voraussetzungen wie 'unsafe-hashes' erforderlich, die Sie nur nach sorgfältiger Sicherheitsbewertung verwenden sollten. Auch ein Nonce ist kein vollständiger Schutz gegen jede XSS-Schwachstelle, da Angreifer bei bestimmten Fehlern Werte aus dem DOM auslesen oder andere erlaubte Ausführungspfade missbrauchen können.

In modernen Browsern wird 'unsafe-inline' für Skripte in Richtlinien mit gültigen Nonces oder Hashes in der Regel ignoriert. Für ältere Browser kann die Angabe dennoch wirksam sein und damit den Schutz schwächen. Sie sollten 'unsafe-inline' und 'unsafe-eval' deshalb möglichst vermeiden und betroffene Altkomponenten schrittweise modernisieren.

CSP-Systeme im Informationsmanagement

Informationsmanagementsysteme bündeln, strukturieren, verwalten und veröffentlichen Daten aus unterschiedlichen Quellen. Dazu gehören Produktinformationen aus PIM-Systemen, Mediendateien aus DAM-Lösungen, Inhalte aus CMS, Dokumente aus Dokumentenmanagementsystemen sowie Stamm- und Geschäftsdaten aus ERP- oder CRM-Systemen. Sobald diese Informationen über Browseroberflächen bereitgestellt werden, entstehen technische Abhängigkeiten, die eine CSP sichtbar machen und begrenzen kann.

Ein B2B-Produktportal kann beispielsweise Produktdaten aus einem PIM-System beziehen, Bilder über ein CDN ausliefern, Verfügbarkeiten über eine ERP-API abrufen und Kontaktanfragen an ein CRM übermitteln. Die CSP kann festlegen, welche Bildquelle, API-Verbindung und welches Formularziel der Browser verwenden darf. Sie bestätigt jedoch nicht, ob diese Systeme selbst vertrauenswürdig, verfügbar oder gegen Angriffe abgesichert sind.

Besonders relevant ist CSP in Informationsmanagement-Szenarien, wenn mehrere Fachabteilungen Inhalte pflegen, Daten automatisiert synchronisiert werden oder Partner Dateien in Portale hochladen. Auch externe Widgets, eingebettete Videos, Analysewerkzeuge und Tag-Manager erhöhen die Komplexität. Ein Tag-Manager kann eine restriktive CSP erheblich erschweren, weil er weitere Skripte und Netzwerkverbindungen dynamisch nachlädt.

Drittanbieter-Skripte sollten Sie wie sicherheitskritische Abhängigkeiten behandeln. Ein erlaubtes externes Skript kann im Kontext Ihrer Seite häufig weitreichende Funktionen ausführen und auf Inhalte zugreifen, die im Browser verfügbar sind. CSP begrenzt zwar, von wo das Skript stammen darf, kontrolliert aber nicht dessen interne Logik oder Datenverarbeitung.

CSP und ergänzende Sicherheitsmaßnahmen

CSP ist eine Schutzschicht im Browser und kann keine serverseitigen Sicherheitslücken beheben. Sie verhindert weder SQL-Injections noch Server-Side-Request-Forgery, fehlende Berechtigungsprüfungen, Datenlecks auf dem Server oder den Missbrauch einer erlaubten API. Deshalb muss CSP immer mit sicheren Entwicklungs- und Betriebsprozessen kombiniert werden.

Wichtige ergänzende Maßnahmen sind:

• serverseitige Eingabevalidierung
• kontextbezogenes Output-Encoding
• sichere Authentifizierung und Session-Verwaltung
• Rollen- und Berechtigungskonzepte
• aktuelle CMS-, Framework- und Bibliotheksversionen
• abgesicherte APIs und Schnittstellen
• HTTPS, HSTS und sichere Cookie-Einstellungen
• regelmäßige Sicherheitsprüfungen und Penetrationstests
• dokumentierte Freigabeprozesse für Drittanbieter-Dienste

Trusted Types können moderne Anwendungen zusätzlich gegen bestimmte DOM-basierte XSS-Schwachstellen absichern. Mit require-trusted-types-for 'script' lässt sich festlegen, dass gefährliche DOM-Senken nur mit geprüften Trusted-Type-Werten verwendet werden dürfen. Die Einführung erfordert allerdings Anpassungen im Frontend-Code und sollte sorgfältig getestet werden.

Subresource Integrity, kurz SRI, ergänzt CSP bei externen Skripten und Stylesheets. SRI hinterlegt einen kryptografischen Hash direkt am eingebundenen Element und stellt sicher, dass der Browser nur genau die erwartete Ressourcenversion lädt. Die CSP-Direktive require-sri-for ist dagegen nicht breit genug unterstützt, um sie allgemein als Standardmaßnahme zu empfehlen.

CSP richtig einführen

Eine CSP sollte nicht ohne Vorbereitung im produktiven Enforce-Modus aktiviert werden. Zu restriktive Regeln können Funktionen beeinträchtigen, wenn Skripte, Stylesheets, Bilder, APIs oder externe Dienste noch nicht korrekt erfasst sind. Ein schrittweises Vorgehen reduziert das Risiko und erleichtert die Zusammenarbeit von Entwicklung, IT-Sicherheit, Betrieb und Fachbereichen.

Ressourcen und Abhängigkeiten erfassen

Ermitteln Sie zunächst alle Ressourcen, die Ihre Anwendung tatsächlich nutzt. Berücksichtigen Sie neben der Hauptanwendung auch dynamisch nachgeladene Inhalte, Single-Page-Applications, Tag-Manager, Consent-Zustände und browserabhängige Funktionen. Dokumentieren Sie dabei, welcher Dienst welche Quelle benötigt und wer für die technische Freigabe verantwortlich ist.

Prüfen Sie insbesondere JavaScript-Dateien, Stylesheets, Webfonts, Bilder, Videos, Dokumente, API-Endpunkte, WebSockets, iFrames, Zahlungsanbieter und Upload-Funktionen. Berücksichtigen Sie auch Unterdomains, verschiedene Mandanten, Sprachversionen sowie administrative Oberflächen. Eine vollständige Bestandsaufnahme verbessert nicht nur die CSP, sondern auch Wartbarkeit und Risikobewertung Ihrer Anwendung.

Mit Report-Only beginnen

Starten Sie mit Content-Security-Policy-Report-Only, bevor Sie eine Richtlinie verbindlich durchsetzen. In diesem Modus erkennen Sie, welche Ressourcen bei einer aktiven CSP blockiert würden, ohne den laufenden Betrieb unmittelbar zu beeinflussen. Report-Only sollte in realistischen Nutzungsszenarien ausreichend lange beobachtet werden, da manche Funktionen nur selten oder nach bestimmten Nutzerinteraktionen geladen werden.

CSP-Reports müssen fachlich eingeordnet werden. Sie können auf eine vergessene Abhängigkeit, eine fehlerhafte Konfiguration oder einen nicht dokumentierten Tag-Manager-Eintrag hinweisen. Häufig entstehen sie aber auch durch Browser-Erweiterungen, nicht mehr verfügbare Ressourcen, technische Änderungen oder individuelles Nutzerverhalten und sind daher kein eindeutiger Beleg für einen Sicherheitsvorfall.

Freigaben präzise definieren

Geben Sie nur Quellen frei, die nachweislich erforderlich sind. Verwenden Sie möglichst konkrete Origins und vermeiden Sie breit gefasste Wildcards. Prüfen Sie insbesondere Skriptfreigaben streng, da externe JavaScript-Dateien im Browser besonders weitreichende Auswirkungen haben können.

Eine restriktive Ausgangskonfiguration umfasst häufig mindestens default-src 'self', object-src 'none', base-uri 'self', ein enges script-src, ein passendes connect-src, form-action und frame-ancestors. Ergänzen Sie Reporting und dokumentieren Sie für jede Ausnahme den technischen Zweck. Entfernen Sie nicht mehr benötigte Freigaben zeitnah.

Umfassend testen

Testen Sie nicht nur die Startseite, sondern alle wichtigen Nutzungsszenarien. Dazu gehören authentifizierte Bereiche, Formulare, Zahlungsprozesse, Downloads, Fehlerseiten, Sprachversionen, Consent-Zustände, administrative Oberflächen und Funktionen auf Subdomains. Prüfen Sie bei modernen Anwendungen zusätzlich Service Worker, Web Worker, WebSockets und dynamisch geladene Komponenten.

Browser-DevTools, automatisierte Header-Scanner und spezialisierte CSP-Evaluatoren helfen dabei, Verstöße und riskante Richtlinien zu erkennen. Ergänzen Sie diese Werkzeuge durch Regressionstests, damit neue Releases nicht unbemerkt erforderliche Ressourcen blockieren oder unzulässig breite Freigaben einführen. CSP-Prüfungen sollten Bestandteil Ihrer Deployment-Pipeline und Security-Header-Tests sein.

Richtlinien versionieren und pflegen

Eine CSP ist keine einmalige Header-Konfiguration. Neue Funktionen, Änderungen im CMS, neue Dienstleister, Kampagnen, APIs oder Frontend-Bibliotheken können Anpassungen erforderlich machen. Verwalten Sie Richtlinien deshalb versioniert im Quellcode oder in nachvollziehbar dokumentierten Konfigurationsprozessen.

Überprüfen Sie die CSP insbesondere nach Releases, Template-Änderungen, CDN-Umstellungen, neuen Drittanbieter-Diensten und Sicherheitsvorfällen. Stimmen Sie die Richtlinie regelmäßig mit den tatsächlich eingebundenen Diensten ab. Nur wenn Konfiguration, Dokumentation, Monitoring und Change-Management zusammenspielen, verbessert CSP auch die Auditierbarkeit.

Mehrere CSP-Header und typische Fehler

Es können mehrere CSP-Header ausgeliefert werden. Browser setzen diese Richtlinien gemeinsam durch, sodass eine zusätzliche Richtlinie Einschränkungen verschärfen kann. Sie kann jedoch keine bestehende Einschränkung lockern, weshalb mehrere unabhängig gepflegte Header unbeabsichtigt zu Funktionsstörungen führen können.

Ein häufiger Fehler sind zu breite Freigaben für Skripte oder Verbindungen. Auch die dauerhafte Nutzung von 'unsafe-inline' oder 'unsafe-eval' schwächt den Schutz deutlich und deutet oft auf technischen Modernisierungsbedarf hin. Nicht benötigte Ausnahmen sollten Sie entfernen, statt sie aus Bequemlichkeit dauerhaft zu übernehmen.

Ebenso problematisch ist die Annahme, eine erlaubte Quelle sei automatisch sicher. CSP prüft nur, ob die Quelle gemäß Richtlinie zulässig ist, nicht ob sie kompromittiert wurde, datenschutzkonform arbeitet oder sichere Inhalte liefert. Besonders bei Drittanbieter-Skripten, CDNs und Tag-Managern sind sorgfältige Auswahl, Verträge, Wartung und regelmäßige Überprüfung erforderlich.

Häufige Fragen zu CSP-Systemen

Was bedeutet CSP-System?

CSP-System ist kein einheitlich definierter technischer Standardbegriff. In der Praxis bezeichnet er meist die Verwaltung einer Content Security Policy einschließlich Richtlinienerstellung, Header-Auslieferung, Reporting, Monitoring und laufender Pflege. Die eigentliche CSP ist eine browserseitige Sicherheitsrichtlinie.

Wovor schützt eine Content Security Policy?

Eine sorgfältig konfigurierte CSP kann bestimmte XSS-Angriffe und das Laden nicht vorgesehener Ressourcen erheblich erschweren. Sie schützt jedoch nicht zuverlässig vor jeder XSS-Variante, nicht vor kompromittierten erlaubten Quellen und nicht vor serverseitigen Sicherheitslücken. CSP ist daher eine zusätzliche Schutzschicht, kein vollständiger Sicherheitsmechanismus.

Was ist der Unterschied zwischen Enforce-Modus und Report-Only-Modus?

Der Header Content-Security-Policy setzt eine Richtlinie aktiv durch und blockiert nicht erlaubte Ressourcen. Content-Security-Policy-Report-Only meldet mögliche Verstöße, blockiert aber nichts. Report-Only eignet sich für Analyse und Tests, bietet allein jedoch keine Schutzwirkung.

Kann eine CSP Funktionen auf meiner Website blockieren?

Ja. Nicht freigegebene Skripte, Stylesheets, Bilder, APIs, Frames oder Schriftarten werden im Enforce-Modus blockiert. Beginnen Sie deshalb mit Report-Only und testen Sie alle relevanten Nutzungsszenarien, bevor Sie die Richtlinie verbindlich aktivieren.

Was ist der Unterschied zwischen frame-src und frame-ancestors?

Mit frame-src bestimmen Sie, welche externen Inhalte Ihre Anwendung in Frames oder iFrames einbetten darf. Mit frame-ancestors legen Sie fest, welche externen Websites Ihre eigene Anwendung einbetten dürfen. frame-ancestors hilft gegen Clickjacking und muss per HTTP-Header ausgeliefert werden.

Was ist der Unterschied zwischen CSP und HTTPS?

HTTPS verschlüsselt die Kommunikation zwischen Browser und Server und schützt Daten auf dem Transportweg. CSP regelt dagegen, welche Ressourcen der Browser unter bestimmten Bedingungen laden oder ausführen darf. Beide Maßnahmen erfüllen unterschiedliche Aufgaben und sollten gemeinsam eingesetzt werden.

Sind Nonces sicherer als unsafe-inline?

Richtig implementierte Nonces sind deutlich sicherer als eine pauschale Freigabe über 'unsafe-inline'. Sie müssen pro HTTP-Antwort kryptografisch zufällig erzeugt und sicher in Header sowie HTML eingebunden werden. Wiederverwendete, vorhersagbare oder durch Caching verbreitete Nonces schwächen den Schutz erheblich.

Muss jede Website eine Content Security Policy verwenden?

Eine CSP ist nicht für jede Website gesetzlich verpflichtend. Sie ist jedoch für viele Webanwendungen eine sinnvolle Sicherheitsmaßnahme, insbesondere bei Login-Bereichen, Formularen, Portalen, Drittanbieter-Skripten oder geschäftskritischen Daten. Der Nutzen hängt von einer sorgfältigen, zur Anwendung passenden Konfiguration ab.

Ist eine Content Security Policy für Informationsmanagementsysteme sinnvoll?

Ja, wenn Ihr Informationsmanagementsystem Inhalte über Produktkataloge, Händlerportale, Kundenbereiche oder interne Webanwendungen bereitstellt. CSP kann die im Browser zulässigen Quellen für Medien, Skripte und Schnittstellen begrenzen. Sie ersetzt aber keine Berechtigungskonzepte, sichere Schnittstellen, Eingabevalidierung oder Schutzmaßnahmen in den angebundenen Quellsystemen.