Defaults.Exposed › Behebungen › Content-Security-Policy (CSP)

So beheben Sie Content-Security-Policy (CSP)

Eine Content Security Policy ist eine Sicherheitsregel, die Ihre Website dem Browser jedes Besuchers übergibt und ihm genau sagt, welcher Code ausgeführt werden darf. Ohne sie wird der Browser, falls je etwas Bösartiges auf eine Seite gelangt — über ein Kommentarfeld, ein gehacktes Plugin oder ein Drittanbieter-Skript —, es frei ausführen, einschließlich Code, der still und leise die Kartennummern und Passwörter Ihrer Kunden abgreift, während sie sie tippen, mit weiterhin angezeigtem Schloss-Symbol.

Das Wichtigste für Ihr Unternehmen: Wenn Ihre Seite je manipuliert wird, kann bösartiger Code die Zahlungskarten- und Login-Daten Ihrer Kunden direkt von Ihrer eigenen Kasse lesen, während alles völlig normal aussieht — und Ihnen Rückbuchungen, Betrugsansprüche, eine meldepflichtige Datenschutzverletzung und einen Prüfungs-Durchfaller bescheren, den die Sicherheitsteams größerer Kunden nutzen, um ein Geschäft zu blockieren oder zu beenden.

Was Sie das kosten kann

• Verborgener Code schleicht sich auf eine Ihrer Seiten und kopiert still und leise jede Kartennummer und jedes Passwort, das Ihre Kunden an der Kasse eingeben, und sendet es an einen Angreifer, während Ihre Seite völlig normal aussieht — Sie erfahren es erst, wenn die Betrugsbeschwerden eintreffen.
• Ein Betrüger platziert ein gefälschtes 'Hier zahlen'-Formular auf Ihrer echten Website, das Zahlungen auf sein eigenes Konto erfasst; Kunden denken, sie hätten an Sie gezahlt, geben Ihnen die Schuld, wenn die Ware nie kommt, und fordern ihr Geld zurück.
• Das Sicherheitsteam eines größeren Kunden scannt Ihre Seite, sieht, dass dieser grundlegende Schutz ausgeschaltet ist, und markiert ihn — was den Vertrag ins Stocken bringt oder Sie ihn verlieren lässt, bis Sie die Behebung belegen können.
• Eine auf eine fehlende Standardsicherung zurückgeführte Sicherheitsverletzung wird zu einem meldepflichtigen Vorfall: Fragen der Aufsichtsbehörde, Kundenbenachrichtigungen und ein Imageschaden, der weit mehr kostet als die kostenlose Behebung.

Warum es wichtig ist. Das Schloss-Symbol beweist, dass die Verbindung zu Ihrer Seite privat ist, aber es tut nichts, um zu steuern, welcher Code läuft, sobald ein Besucher auf der Seite ist. Eine Content Security Policy ist die Sicherung, die das tut — sie sagt Browsern, jedes Skript zu ignorieren, das nicht von einer Quelle kam, der Sie vertrauen, sodass ein einzelnes manipuliertes Feld, eine Anzeige oder ein Plugin nicht zu einem Werkzeug umfunktioniert werden kann, um das Geld und die Daten Ihrer Kunden zu stehlen. Es ist eine bewertete Prüfung auf Ihrer Bewertungskarte, echte Punkte wert, und eines der ersten Dinge, nach denen eine professionelle Sicherheitsprüfung sucht.

Was das ist, in einfachen Worten

Wenn jemand Ihre Website besucht, lädt sein Browser Ihre Seite herunter und führt jeden Code aus, der darauf ist — die Skripte, die Menüs herunterklappen lassen, Schaltflächen funktionieren lassen, Zahlungsformulare absenden und so weiter. Standardmäßig vertraut der Browser all dem. Er hat keine Möglichkeit zu wissen, welcher Code echt Ihrer ist und welcher von jemand anderem eingeschleust wurde.

Eine Content Security Policy (oft zu CSP verkürzt) ist eine kurze Liste von Regeln, die Ihre Website jeder Seite anhängt und die dem Browser sagt: „führe nur Code von diesen Quellen aus, die ich genehmigt habe, und weise alles andere ab.” Es ist der Unterschied zwischen einem Nachtclub, der jeden hineinlässt, und einem mit einer Gästeliste an der Tür.

Der Grund, warum das so wichtig ist, ist, dass Websites ständig manipuliert werden — nicht immer durch das Hacken Ihres Servers, sondern durch die Hintertüren, die die meisten Seiten offenlassen: ein Kommentarfeld, ein Suchfeld, ein veraltetes Plugin, ein Drittanbieter-Skript für Anzeigen oder Analyse oder ein Chat-Widget. Wenn ein Angreifer auch nur eine Zeile seines eigenen Codes auf eine Ihrer Seiten bekommt, führt der Browser ihn aus, als wäre er Ihrer. Von dort aus kann er alles lesen, was Ihre Kunden tippen — Kartennummern, Passwörter, Adressen — und es still und leise woandershin senden. Eine Content Security Policy schließt diese Tür, indem sie sich weigert, irgendetwas von einer Quelle auszuführen, die Sie nicht genehmigt haben.

Was Sie das kosten kann

Das ist nicht abstrakt. Der Angriff, den eine Content Security Policy verhindert — in eine Seite eingeschleuster Code, der Daten von Ihren eigenen Kunden stiehlt — steckt hinter einigen der größten Kartenskimming-Datenschutzverletzungen, die je verzeichnet wurden. So spielt es sich für ein normales Unternehmen meist ab:

• Der unsichtbare Kassen-Skimmer. Ein Angreifer schleust über ein verwundbares Plugin oder ein kompromittiertes Drittanbieter-Skript ein paar Zeilen Code auf Ihre Kassenseite. Jede Kartennummer, jeder Name und jede Prüfziffer, die Ihre Kunden tippen, wird in Echtzeit kopiert und an den Angreifer gesendet. Ihre Seite sieht aus und funktioniert perfekt; das Schloss-Symbol ist da. Sie entdecken es Wochen später, wenn Ihr Zahlungsanbieter wegen einer Häufung von Betrugsmeldungen anruft, die alle auf Ihren Shop zurückführen. Nun stehen Sie vor Rückbuchungen, einem erzwungenen Sicherheitsaudit, möglichem Verlust der Kartenverarbeitungs-Rechte und einer Datenschutzverletzung, die Sie womöglich gesetzlich melden müssen.

• Das gefälschte Zahlungsformular. Ein Betrüger schleust ein überzeugendes „Hier zahlen”-Feld auf Ihre echte Website. Kunden geben ihre Daten ein und vertrauen Ihrer Marke; das Geld und die Daten gehen an den Angreifer. Die Kunden geben Ihnen die Schuld — und liegen damit nicht falsch, denn es geschah auf Ihrer Seite.

• Der verlorene Auftrag. Das Sicherheitsteam eines größeren Interessenten führt im Rahmen der Lieferanten-Due-Diligence einen automatischen Scan Ihrer Seite durch. Eine fehlende Content Security Policy taucht sofort als Lücke hoher Schwere auf. Für einen Einkaufs- oder Sicherheitsprüfer liest sich diese eine fehlende Sicherung als „dieser Lieferant macht die Grundlagen nicht” — und das Geschäft stockt, während sie um Behebung bitten, oder geht still an einen Wettbewerber, der bestanden hat.

• Die meldepflichtige Datenschutzverletzung. Wenn eine Datenschutzverletzung auf eine fehlende, standardmäßige, kostenlose Sicherung zurückgeführt wird, hört sie auf, Pech zu sein, und beginnt, wie Fahrlässigkeit auszusehen. Das ändert die Fragen der Aufsichtsbehörde, die Kundenbenachrichtigungspflicht und die Kosten — sowohl das Bußgeld als auch den Imageschaden, der lange nach Abschluss des Vorfalls anhält.

• Die kompromittierte Anzeige oder das Widget. Viele Seiten laden Code von Drittparteien — Werbenetzwerke, Schriften, Support-Chat, Analyse. Wenn auch nur eine davon kompromittiert wird, reitet der bösartige Code direkt in Ihre Seiten. Eine Content Security Policy begrenzt den Wirkungsradius, indem sie nur die konkreten externen Quellen zulässt, denen Sie vertrauen, sodass die Datenschutzverletzung eines Lieferanten nicht automatisch zu Ihrer wird.

Was es eigentlich ist (das Detail)

Eine Content Security Policy wird als einzelner HTTP-Antwort-Header ausgeliefert — eine Zeile, die Ihr Webserver mit jeder Seite sendet. Ihr Wert ist ein Satz von Direktiven, von denen jede eine Art von Inhalt und die dafür erlaubten Quellen benennt. Zum Beispiel:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

In Klartext sagt das: Lade standardmäßig nur Dinge von meiner eigenen Seite; führe nur Skripte von meiner eigenen Seite aus; erlaube keine alten Plugins; und lass andere Seiten meine nicht in einem Frame einbetten.

Wie „gut” aussieht. Unsere Prüfung sucht nicht nur nach dem Vorhandensein des Headers — sie liest die Richtlinie Direktive für Direktive und bewertet, wie stark sie tatsächlich ist, so wie es ein Sicherheitsprüfer täte. Eine starke Richtlinie:

• Setzt eine restriktive Basis (default-src 'self') und weitet sie nur für die konkreten vertrauenswürdigen Drittparteien aus, die Sie wirklich nutzen.
• Vermeidet die Schlupflöcher. Sie verwendet nicht 'unsafe-inline' oder 'unsafe-eval' für Skripte und verwendet keine Wildcard- (*) oder nackten Schema-Quellen (wie https:) für Skripte — diese öffnen faktisch die Tür wieder, die die Richtlinie schließen soll. Wo Inline-Skripte wirklich nötig sind, verwendet sie eine Nonce oder einen Hash, sodass nur Ihr konkreter genehmigter Code läuft.
• Verriegelt das Framing mit frame-ancestors 'self' (das blockiert auch den „betten Sie Ihre Seite ein, um Ihre Kunden zu täuschen”-Angriff) und deaktiviert alte Plugins mit object-src 'none'.
• Ist durchsetzend, nicht nur Bericht. Ein Content-Security-Policy-Report-Only-Header beobachtet nur; er bietet null Laufzeit-Schutz. Unsere Prüfung gibt ihm einen kleinen Bruchteil der Anrechnung und verbucht ihn nie als Bestehen. Sie sind erst geschützt, sobald die Richtlinie durchsetzt.

Eine Richtlinie, die existiert, sich aber auf 'unsafe-inline', 'unsafe-eval' oder Wildcards stützt, schneidet trotzdem schlecht ab — weil sie in der Praxis wenig echten Schutz bietet. Das Ziel ist eine straffe Richtlinie, nicht irgendeine Richtlinie.

So beheben Sie es (kostenlos, ~1–2 Stunden)

Geben Sie das an Ihren IT-Menschen oder die Person, die Ihre Website betreibt — die Behebung selbst ist vollständig kostenlos. Wir berechnen ausschließlich die Überwachung, dass es vorhanden und über die Zeit korrekt bleibt; das Einschalten kostet nichts. Der Grund, warum das eine oder zwei Stunden statt Minuten dauert, ist der sorgfältige Versuchsschritt, der verhindert, dass es versehentlich Teile Ihrer eigenen Seite blockiert.

1. Starten Sie im Nur-Bericht-Modus — setzen Sie noch nicht durch. Fügen Sie einen Content-Security-Policy-Report-Only-Antwort-Header hinzu. Das beobachtet und protokolliert, was blockiert würde, ohne tatsächlich etwas zu blockieren, sodass die Live-Seite weiterläuft, während Sie lernen, wovon jede Seite wirklich abhängt. (Wichtig: Nur-Bericht für sich allein gibt Besuchern keinen Schutz — es ist nur der sichere erste Schritt.)

2. Bauen Sie die Richtlinie aus dem, was Ihre Seite tatsächlich nutzt. Prüfen Sie die Berichte, um jede legitime Quelle von Skripten, Stilen, Schriften und Bildern zu finden — Ihre eigene Domain, Ihre Analyse, Ihren Zahlungsanbieter, Ihren Schriften-Host, Ihr Chat-Widget — und listen Sie sie als erlaubte Quellen auf. Ein solider Ausgangspunkt ist default-src 'self' plus explizite Einträge für die vertrauenswürdigen Drittparteien, die Sie wirklich nutzen.

3. Vermeiden Sie die Schlupflöcher, die den ganzen Sinn zunichtemachen. Halten Sie sich von 'unsafe-inline' und 'unsafe-eval' für Skripte fern und vermeiden Sie Wildcard-Quellen wie * und nackte Schemata wie https: für Skripte — diese öffnen genau die Lücke wieder, die die Richtlinie schließen soll. Wo Inline-Skripte unvermeidlich sind, verwenden Sie eine Nonce oder einen Hash, sodass nur Ihr konkreter genehmigter Code läuft.

4. Verriegeln Sie Framing und Plugins. Fügen Sie frame-ancestors 'self' hinzu (das stoppt auch, dass andere Seiten Ihre einbetten, um Ihre Kunden zu täuschen, und erfüllt die verwandte Clickjacking-Prüfung) und object-src 'none', um alte plugin-basierte Angriffe zu blockieren.

5. Wechseln Sie von Nur-Bericht zu durchsetzend. Sobald die Berichte sauber sind und die Seite funktioniert, ändern Sie den Header-Namen von Content-Security-Policy-Report-Only zu Content-Security-Policy. Das ist der Schritt, der tatsächlich Schutz liefert — eine reine Nur-Bericht-Richtlinie tut das nicht und wird die Prüfung nicht bestehen.

   Wo Sie den Header setzen, hängt von Ihrer Plattform ab:

   • Cloudflare: Rules → Transform Rules → Modify Response Header → Content-Security-Policy setzen. (Sie können Cloudflare auch für den Nur-Bericht-Versuch nutzen.)
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
   • IIS (web.config): Fügen Sie einen benutzerdefinierten HTTP-Antwort-Header namens Content-Security-Policy mit der Richtlinie als Wert hinzu.
   • Google Workspace / Microsoft 365: Diese betreiben Ihre E-Mail, nicht Ihre öffentliche Website, sodass die Richtlinie dort gesetzt wird, wo Ihre Website tatsächlich gehostet wird (Cloudflare oder Ihr Webhoster oben), nicht in Ihrer E-Mail-Verwaltung.

6. Prüfen Sie Ihre Domain erneut, um zu bestätigen, dass die Richtlinie nun als eingeschaltet und durchsetzend angezeigt wird, ohne schwächende Schlupflöcher.

Häufige Fehler

• Bei Nur-Bericht aufhören. Der mit Abstand häufigste Fehler: Eine Richtlinie wird im Nur-Bericht-Modus hinzugefügt, alle machen weiter, und die Seite ist nie tatsächlich geschützt. Nur-Bericht blockiert nichts. Sie müssen zu durchsetzend wechseln.
• Zu 'unsafe-inline' greifen, damit es „einfach funktioniert”. Wenn die Richtlinie ein legitimes Inline-Skript blockiert, ist die schnelle Lösung, alle Inline-Skripte zu erlauben — aber das öffnet genau das Loch wieder, das die Richtlinie schließen sollte. Verwenden Sie stattdessen eine Nonce oder einen Hash.
• Einen Wildcard verwenden. Ein nacktes * (oder https:) in script-src erlaubt Skripte von überall, was bedeutet, dass die Richtlinie fast keinen echten Schutz bietet und trotzdem niedrig abschneidet.
• Drittanbieter-Quellen vergessen. Eine strenge Richtlinie durchzusetzen, ohne zuerst die legitimen externen Dienste aufzulisten, die Sie nutzen (Analyse, Schriften, Zahlungs-Widgets), kann Teile Ihrer eigenen Seite lahmlegen — was genau der Grund ist, warum der Nur-Bericht-Versuchsschritt existiert.
• Es nur auf der Startseite setzen. Die Richtlinie muss jede Seite abdecken, besonders Kassen-, Login- und Kontoseiten — das sind die, die sich anzugreifen lohnt.
• Es als Ersatz für das Schloss-Symbol behandeln. Eine Content Security Policy und HTTPS/HSTS schützen verschiedene Dinge. Sie wollen alle; eines deckt nicht das andere ab.

FAQ