Zum Inhalt
Startseite » Innovatives Webdesign » Website Content Security Policy (CSP) verstehen

Website Content Security Policy (CSP) verstehen

Stand: Oktober 11, 2026

Webseitensicherheit beschränkt sich nicht nur auf Firewalls und starke Passwörter. Ein Großteil der Angriffe in der Praxis findet im Browser des Besuchers statt, wo eingeschleuste Skripte Daten stehlen oder eine Sitzung übernehmen können.

Dazu gehören auch der Datenschutz im Internet und der Aufbau einer Abwehr gegen Schadcode oder andere Code-Injection-Angriffe.

Dieser Artikel konzentriert sich auf eine Sicherheitsmaßnahme, die Inhaltssicherheitsrichtlinie.

Die Content Security Policy ist in erster Linie für die Clientseite von Webanwendungen konzipiert. Die Sicherheitsmaßnahme bietet modernen Browsern umfassenden Schutz vor schädlichen Inhalten.

Lesen Sie weiter, um mehr über diese Sicherheitsfunktion und ihre Einrichtung zu erfahren.

Was ist die Inhaltssicherheitsrichtlinie einer Website?

Eine Content Security Policy (CSP) ist ein Sicherheitsstandard. Sie schützt Websites und Anwendungen vor verschiedenen Angriffen wie Cross-Site-Scripting (XSS). Die CSP ist ein HTTP-Antwortheader, der die Sicherheit von Webseiten in gängigen modernen Browsern verbessert.

Der Content Security Policy Header funktioniert, indem er die Inhaltsquellen (wie Skripts und Bilder) einschränkt, die eine Webseite laden kann und von denen sie geladen werden kann. 

Quelle

Wenn Sie den HTTP-Antwortheader für Content Security Policy (CSP) in einem Browser implementieren, der diesen nicht unterstützt, ignoriert der Browser ihn. Standardmäßig wird die Same-Origin-Policy (eine weitere Schutzmaßnahme gegen Schadcode) verwendet. Der Browser kann jedoch weiterhin mit einem Server kommunizieren, der CSP unterstützt, und umgekehrt.

Beachten Sie, dass CSP eine zusätzliche Sicherheitsebene gegen verschiedene Arten von Schwachstellen darstellt. Das Schlüsselwort hier ist „zusätzlich“. Mit anderen Worten: Sie müssen Ihre Webseite weiterhin mit anderen Sicherheitsmaßnahmen schützen. 

Erwähnenswert ist auch, dass CSP Ihre Webseite nicht vor Angriffen schützt. Es erkennt diese Angriffe jedoch effektiv und reduziert deren Ausnutzungsrisiko erheblich. 

Bedeutung der Sicherheitsrichtlinie für Website-Inhalte

Sie implementieren den Content Security Policy-Header (CSP), um die Inhaltsquellen zu steuern, die Ihre Website laden darf. Die CSP-Implementierung kann auf jeder Website verwendet werden, egal ob es sich um einen Onlineshop oder einen Blog handelt. 

Es hilft:

XSS-Angriffe abschwächen

Wir haben bereits erwähnt, dass CSP dazu beitragen kann, XSS-Angriffe einzudämmen. Aber was genau sind diese und wie kann CSP helfen? 

XSS ist eine Sicherheitslücke, die es Angreifern ermöglicht, Schadcode in Webseiten einzuschleusen. Eine XSS-Schwachstelle auf Ihrer Webseite öffnet Tür und Tor für Angriffe wie Datendiebstahl und Website-Manipulation. XSS zählt seit Jahren zu den zehn größten Risiken für Webanwendungen laut OWASP und ist nach wie vor eine der am häufigsten gemeldeten Sicherheitslücken in WordPress-Plugins.

CSP schützt vor XSS-Angriffen, indem es Inline-Skripte einschränkt. Es verhindert außerdem, dass Ihre Webseite Remote-Skripte, d. h. Skripte von beliebigen Servern, lädt.

CSP schützt Ihre Website außerdem vor XSS-Angriffen, indem es die Übermittlung von HTML-Formularen kontrolliert. Selbst wenn Besucher Kreditkartendaten für den Kauf eines Produkts angeben oder LLC-Mitgliedszertifikate online ausfüllen, bleiben ihre Daten geschützt. CSP schränkt grundsätzlich die Verwendung der Daten aus diesen Formularen ein. Darüber hinaus schränkt CSP den HTML-Objekt-Tag ein.

CSP schwächt außerdem XSS-Angriffe ab, indem es Serveradministratoren ermöglicht, die Domänennamen anzugeben, die der Browser als gültige Quellen ausführbarer Skripts betrachten soll.

Letztendlich wird Angreifern dank CSP das Einschleusen schädlicher Skripte untersagt.

Clickjacking verhindern

Obwohl CSP in erster Linie eingeführt wurde, um die Angriffsfläche von XSS-Angriffen zu verringern, wurde es auch entwickelt, um Schutz vor Angriffen auf Webanwendungen wie Clickjacking zu bieten.

Beim Clickjacking bringt der Angreifer einen Benutzer dazu, auf eine Schaltfläche oder einen Link auf einer als etwas anderes getarnten Webseite zu klicken. 

Wenn Sie keine Dienste von Anbietern für Identitätsdiebstahlschutz in Anspruch nehmen, können Sie Opfer von Clickjacking-Angreifern werden. Sie werden es erst bemerken, wenn bereits erheblicher Schaden entstanden ist, beispielsweise durch Geldüberweisungen oder Online-Käufe. 

Früher war der X-Frame-Options-Header der Standardschutz gegen Clickjacking. Die Frame-Ancestors-Direktive von CSP (eingeführt in CSP Level 2 und Teil des aktuellen Level-3-Entwurfs) erfüllt dieselbe Funktion, bietet aber mehr Flexibilität und wird von modernen Browsern priorisiert. Viele Websites senden für ältere Browser weiterhin beide Header.

CSP-Level 2 enthält eine Anti-Clickjacking -Direktive namens „frame - ancestors“ . Diese Direktive legt die URL der übergeordneten Seite fest, die eine Webseite in einen Frame, iFrame oder ein Objekt der aktuellen Ressource einbetten darf.

Im Wesentlichen schränken Sie damit die Seiten ein, die die aktuelle Seite in einen Frame einbetten dürfen. Ein Beispiel für die Verwendung der Direktive `frame-ancestors` ist:

content-security-policy: frame-ancestors 'self' '\*.internxt.com' ;      

Sie können die Direktive frame-ancestors auch zusammen mit den Direktiven default-src und script-src verwenden, um Clickjacking-Angriffe zu reduzieren.

Welche anderen Angriffe verhindert CSP?

CSP kann auch HTTPS erzwingen. Listen Sie in Ihrer Richtlinie nur https://-Quellen auf und fügen Sie die Direktive „upgrade-insecure-requests“ hinzu, damit der Browser alle verbleibenden http://-Ressourcen automatisch über HTTPS lädt. (Die ältere Direktive „block-all-mixed-content“ ist veraltet, da Browser gemischte Inhalte selbstständig blockieren oder aktualisieren.)

Weitere Schwachstellen, die Sie mit CSP beheben können, sind:

  1. Dynamischer Javascript-Code mit eval()
  2. Nicht zugewiesenes Inline-Javascript in tags
  3. Dynamisches CSS mit CSSStylesheet.insertRule()
  4. Nicht zugewiesene Inline-CSS-Anweisungen in tags

So richten Sie eine Inhaltssicherheitsrichtlinie ein

Die Einrichtung von CSP ist ein wesentlicher Schritt zum Schutz Ihrer Webanwendung. Sie können den CSP-Schutz für Ihre Website auf drei Arten einrichten.

Content-Security-Policy-Header

Bei dieser Methode wird der HTTP-Antwortheader „content-security-policy“ vom Webserver gesendet. Beispiel:

Inhaltssicherheitsrichtlinie: …

Stellen Sie sicher, dass Sie den Header in allen HTTP-Antworten konfigurieren.

Meta-Tags zur Inhaltssicherheitsrichtlinie 

Falls Sie den CSP-HTTP-Antwortheader nicht verwenden können, lässt sich CSP für Ihre Website dennoch konfigurieren, indem Sie das Meta-Element „HTTP-equiv“ in der HTML-Datei verwenden. So sieht eine Zeile des CSP-Meta-Tags aus:

Diese Methode schränkt die nutzbaren CSP-Funktionen ein. Beispielsweise können Sie weder Framing-Schutz noch einen Endpunkt zur Protokollierung von CSP-Verletzungen verwenden.

Content-Security-Policy – ​​Nur-Bericht-Header 

Dieser Header weist den Browser an, Richtlinienverstöße zu melden, ohne Inhalte zu blockieren. Die Meldungen werden an den Endpunkt gesendet, den Sie mit der Direktive `report-to` (zusammen mit einem `Reporting-Endpoints`-Header) definieren. Die ältere Direktive `report-uri` ist veraltet, wird aber weiterhin häufig unterstützt, weshalb viele Websites derzeit beide verwenden. Zum Beispiel:

content-security-policy-report-only: script-src 'self'; 

Bericht an CSP-Reporting-Endpunkt 

Der Hauptunterschied zwischen diesem Header und dem regulären CSP-HTTP-Antwortheader besteht darin, dass ersterer die Richtlinie nicht erzwingt. Browser erlauben Websites jedoch die Verwendung sowohl des „Content-Security-Policy“-Headers als auch des „Content-Security-Policy-Report-Only“-Headers.

Details der Implementierung

Sie müssen entscheiden, welche Richtlinien Sie in Ihre Sicherheitsrichtlinie aufnehmen möchten. Richtlinien sind Regeln, die die Arten von Inhalten regeln, auf die die Webbrowser der Benutzer zugreifen dürfen, wie z. B. Bilder, Skriptdateien und Stylesheets.

Dieser Schritt erfolgt vor dem Schreiben Ihrer Website-Inhalte und der Sicherstellung der Sichtbarkeit Ihrer Website. Diese beiden letzten Punkte sind selbst für Website-Neulinge recht einfach umzusetzen. Einer der häufigsten Anwendungsfälle für generative KI ist die Content-Erstellung. Sie müssen also lediglich die richtigen Eingabeaufforderungen eingeben, und die KI erstellt die gewünschten hochwertigen Inhalte.

Mit den vielen kostenlosen SEO-Ressourcen und -Tools, die zur Verfügung stehen, können Sie die gesamte SEO-Arbeit auch selbst durchführen, um die Sichtbarkeit Ihrer Website zu steigern. Für optimale Ergebnisse ist es jedoch ratsam, die Dienste einer SEO-Agentur aus den Bereichen Fertigung, Recht oder SaaS mit umfassender Erfahrung und Expertise in Anspruch zu nehmen. 

Andererseits ist es für Anfänger deutlich schwieriger, spezifische Regeln für jede Domain und Subdomain Ihrer Website zu erstellen. Sie lernen zunächst die verfügbaren Regeln und Probleme kennen. Anschließend wählen Sie aus, welche in Ihre Liste aufgenommen werden sollen, und ergreifen die entsprechenden Maßnahmen (sofern autorisiert) bzw. nicht (sofern gesperrt). Deshalb beauftragen manche lieber Entwickler mit dieser Aufgabe.

Wenn Sie sich der Herausforderung stellen möchten, werfen wir einen genaueren Blick auf die CSP-Direktiven, die wir in den vorherigen Abschnitten erwähnt haben, um Ihnen bei diesem Aspekt Ihrer Website zu helfen:

Fetch-Direktiven 

Sie fügen Fetch-Direktiven in Ihr Antwortheaderfeld ein, um die Speicherorte anzugeben, denen Ihr Browser vertrauen und von denen er Ressourcentypen laden kann. Die meisten Fetch-Direktiven greifen auf default-src zurück. Das bedeutet, dass die Direktivenwerte aus den Standarddirektiven übernommen werden, wenn eine Fetch-Direktive nicht im Antwortheaderfeld aufgeführt ist. 

Beispiele für Fetch-Direktiven sind „child-src“, „font-src“ und „img-src“. 

Dokumentrichtlinien

Dokumentdirektiven in Ihrem CSP-Antwortheaderfeld teilen dem Browser die Eigenschaften der Dokumente mit, auf die die Richtlinie zutrifft. 

Die Direktive „base-URI“ beschränkt beispielsweise die URLs, die das Basiselement des Dokuments verwenden kann. Ein weiteres Beispiel ist die Direktive „sandbox“, die die Aktionen einschränkt, die die Seite ausführen kann. Dokumentdirektiven greifen nicht auf die Standard-Src-Direktive zurück. 

Navigationsanweisungen

Navigationsdirektiven steuern, wohin ein Dokument Benutzer oder Daten weiterleiten kann. Die wichtigsten sind „form-action“, das die URLs einschränkt, an die Formulare gesendet werden können, und „frame-ancestors“, das festlegt, welche Websites Ihre Seite einbetten dürfen. (Eine vorgeschlagene „navigate-to“-Direktive wurde aus der Spezifikation gestrichen und nie in Browsern implementiert.)

Stellen Sie sicher, dass Sie Ihre Sicherheitsrichtlinie regelmäßig aktualisieren, um sicherzustellen, dass Ihre Site nicht anfällig für neue Bedrohungen wird.

Testrichtlinie

CSP kann sich negativ auf eine Website auswirken, wenn es nicht richtig eingerichtet ist. Hier kommen Tests ins Spiel.

Der reine Berichtsmodus ist eine effektive Methode, um zu testen, ob ein CSP ordnungsgemäß funktioniert. Der reine Berichtsmodus bietet Einblicke in die Anzahl der CSP-Verstöße, die bei Durchsetzung der Richtlinie aufgetreten wären, blockiert jedoch nichts.

Mithilfe dieser Testmethode können Websitebesitzer erkennen, wo ihre Richtlinien wahrscheinlich versagen. So können sie sie entsprechend anpassen.

Für die Prüfung der CSP einer Website im reinen Berichtsmodus stehen verschiedene Tools zur Verfügung. Eines der beliebtesten Tools ist der CSP Evaluator. 

Mit diesem Tool können Sie eine URL eingeben. Anschließend prüft das Tool, ob ein CSP-Header vorhanden ist. Außerdem wird angezeigt, ob der CSP ausreichend konfiguriert ist. Gleichzeitig analysiert es die Richtlinie, weist auf potenzielle Probleme hin und zeigt Ihnen, wie Sie diese verbessern können. 

Der folgende Screenshot zeigt einige der Vorschläge des Tools:

Quelle

Alternativ können Sie Scanner wie das MDN HTTP Observatory (den Nachfolger des Mozilla Observatory) oder den CSP Tester verwenden. Diese funktionieren ähnlich wie der CSP Evaluator: Sie prüfen Ihre Header, bewerten Ihre Richtlinie und geben Verbesserungsvorschläge.

Erweiterungen wie Googles CSP Tester und CSP Debugger können Ihnen ebenfalls beim Testen Ihrer CSPs helfen. 

Sie verfolgen die auf einer Webseite geladenen schriftlichen und Videoinhalte sowie deren Quellen und weisen auf etwaige Verstöße gegen die CSP-Richtlinien hin.

Diese Erweiterungen sind sowohl für Chrome als auch für Firefox verfügbar. Sie können zum Testen, Debuggen und Validieren Ihres CSP auf Ihrer Website verwendet werden. Sie können auch Berichte zur Effektivität (oder deren Fehlen) von CSPs erstellen.

Gebote und Verbote zur CSP-Nutzung

CSP ist ein effektives Werkzeug, mit dem Sie die Risiken der Webanwendungssicherheit minimieren können. Wie alle Sicherheitswerkzeuge hat aber auch CSP seine eigenen Regeln und Vorschriften. Es ist wichtig, diese zu verstehen, um es effektiv einsetzen zu können.

Hier sind einige Regeln:

Verwenden Sie eine Nonce-basierte Richtlinie mit der Einstellung „strict-dynamic“. Mit dieser Konfiguration werden nur Skripte ausgeführt, die die korrekte Einmal-Nonce (oder den Hash) enthalten, und alle von ihnen geladenen Skripte werden automatisch als vertrauenswürdig eingestuft. Dadurch ist eine strikte Richtlinie besonders praktikabel für Websites, die Tag-Manager verwenden oder Skripte dynamisch laden, ohne dass eine lange Liste zulässiger Domains verwaltet werden muss.

Inline-Skripte sind Skripte, die direkt in den HTML-Code eingebettet werden, anstatt aus separaten Dateien geladen zu werden. Gemäß einer strengen Richtlinie wird ein Inline-Skript nur ausgeführt, wenn es eine gültige Nonce oder einen passenden Hash enthält; daher wird eingefügter Code ohne diese Angaben blockiert.

Die Verwendung von Inline-Code wird jedoch nicht empfohlen. Die Inline-Direktive erlaubt zwar die Einbindung von Skripten und Styles direkt in Ihren HTML-Code, birgt aber Risiken, da Hacker so Schadcode in Ihre Inhalte einschleusen können. Verwenden Sie stattdessen die Attribute „nonce-value“ und „hash-value“, um Inline-Skripte und Styles aus vertrauenswürdigen Quellen zuzulassen.

Verwenden Sie auch nicht 'eval()'. Die 'eval()'-Direktive erlaubt die Ausführung dynamisch generierter Skripte. Dadurch kann CSP umgangen und beliebiger Code ausgeführt werden, was ein erhebliches Sicherheitsrisiko darstellt.

Wenn Ihre Website stark auf Inline-Skripte und -Stile oder Bibliotheken und Plug-Ins von Drittanbietern angewiesen ist, benötigen Sie möglicherweise Hilfe bei der Implementierung von CSP.

Sie können ein Tool wie den Content Security Policy Builder verwenden, um ein benutzerdefiniertes CSP zu erstellen, das die spezifischen Anforderungen Ihrer Website sowie Bibliotheken und Plug-Ins von Drittanbietern berücksichtigt. 

Hinzufügen eines CSP zu einer WordPress-Website

Unter WordPress können Sie den Header von Ihrem Webserver (Apache .htaccess oder Nginx-Konfiguration), von einem CDN wie Cloudflare mithilfe einer Antwortheader-Regel oder mit einem Sicherheits-Plugin, das benutzerdefinierte Header unterstützt, senden. Unabhängig von der gewählten Methode sollten Sie Folgendes beachten:

  • Starten Sie im reinen Berichtsmodus. Themes, Page-Builder, Analyse- und Zahlungsskripte werden aus vielen Quellen geladen, und eine zu strenge Richtlinie kann schon am ersten Tag zu Problemen beim Bezahlvorgang oder bei Formularen führen.
  • Achten Sie auf das Zwischenspeichern von Seiten. Die Nonce muss bei jeder Antwort unterschiedlich sein. Wenn ein vollständiger Seitencache denselben HTML-Code an alle Nutzer ausliefert, verliert die Nonce ihre Geheimhaltung. Verwenden Sie daher Hashes oder eine Zulassungsliste für zwischengespeicherte Seiten oder generieren Sie Nonces am CDN-Rand.
  • Überprüfung nach den Aktualisierungen. Neue Plugins und Einbettungen von Drittanbietern benötigen oft neue Quellen. Überprüfen Sie daher nach größeren Änderungen Ihre Verstößeberichte erneut.

Beispiele für Inhaltssicherheitsrichtlinien

CSP kann je nach den spezifischen Anforderungen einer Website auf verschiedene Weise implementiert werden. Hier sind einige Beispiele für CSP-Richtlinien zum besseren Verständnis:

  • So konfigurieren Sie Ihren CSP-Header, um Skripte, CSS, AJAX und Bilder vom aktuellen Ursprung zuzulassen, ohne andere Ressourcen zu laden;

Content-Security-Policy: default-src 'none' ; script-src 'self' ; connect-src 'self' ; img-src 'self' ; style-src 'self' ; frame-ancestors 'self' ; form-action 'self' ;  

  • So konfigurieren Sie eine mäßig strenge Richtlinie im Antwortheaderfeld: 

script-src 'nonce-r4nd0m' 'strict-dynamic' ;

object-src 'none' ; base-uri 'none' ;

  • Die CSP-Konfiguration für eine strenge Lockdown-Richtlinie;

script-src 'nonce-r4nd0m'

object-src 'none' ; base-uri 'none' ;

Wichtig zu beachten ist, dass die Implementierung von CSP zwar zur Verbesserung der Sicherheit Ihrer Website beiträgt, aber in Verbindung mit anderen Sicherheitsmaßnahmen wie starken Authentifizierungsprotokollen, regelmäßigen Software-Updates und der Domainregistrierung bei seriösen Anbietern eingesetzt werden sollte, um einen umfassenden Schutz vor Cyberbedrohungen zu gewährleisten.

Weitere Informationen zu Nonce-Attributen für CSP finden Sie auf MDN. Sie können auch dieses Referenzhandbuch nutzen.

Schlusswort

Sicherheit im Web ist nicht zu unterschätzen. Menschen können ihr Geld verlieren und sind (unter anderem) durch Cyberangriffe wie Cross-Site-Scripting und Clickjacking gefährdet. Daher sollte eine Content-Sicherheitsrichtlinie eine notwendige Schutzebene für alle Webanwendungen sein. 

Bewerten Sie Ihre Richtlinien zur Reaktion auf Sicherheitsvorfälle, einschließlich der Systeme, die Sie zur Erkennung von Cybersicherheitsbedrohungen einsetzen, wie z. B. Simulationen von Sicherheitsverletzungen und Angriffen , und wie Sie effektiv mit diesen umgehen werden, falls sie auftreten.

Dennoch müssen Sie im Hinblick auf die Sicherheit bei der Nutzung des Internets Vorkehrungen treffen, um nicht Opfer von Angreifern zu werden.

Indem Sie sich mit den unterschiedlichen Arten von Richtlinien und Protokollen vertraut machen, können Sie nicht nur Ihre Website, sondern auch Ihr Publikum besser schützen, das möglicherweise seine persönlichen Daten auf Ihrer Site geteilt hat.

Google bevorzugte Quelle

Hat Ihnen dieser Leitfaden gefallen? Mehr dazu finden Sie hier. Webnus auf Google.

Speichern Webnus als bevorzugte Quelle und unsere Artikel werden häufiger in Ihren Google Top Stories angezeigt.

Als bevorzugte Quelle hinzufügen

Masoud Varaste

Masoud Varaste ist Schriftsteller bei Webnus mit mehr als 10 Jahren Berufserfahrung als Autor. Seine erste Leidenschaft war das Schreiben, und im Laufe der Zeit kam ein dritter Teil hinzu: WordPress. Heute schreibt er praktische Anleitungen zu WordPress-Themes und -Plugins. WooCommerceEr behandelt Themen wie Hosting, Website-Sicherheit und -Performance und übersetzt technische Sachverhalte in klare, praxisnahe Schritt-für-Schritt-Anleitungen, die Website-Betreiber tatsächlich umsetzen können. Seine Artikel bleiben stets aktuell, um mit den Entwicklungen von WordPress und seinem Ökosystem Schritt zu halten. Vernetzen Sie sich mit Masoud auf LinkedIn..