blueredix logo
SCAN Schwachstellenscans auf Abruf ab 149 €
medium missing-csp

Content Security Policy nicht gesetzt

Eine Content Security Policy ist eine Liste vertrauenswürdiger Quellen für die Skripte, Stile und Einbettungen Ihrer Webseite. Ohne CSP kann ein einzelner Bug einem Angreifer erlauben, eigenen Code in den Browsern Ihrer Besucher:innen auszuführen.

Worum es geht

Eine Content Security Policy (CSP) ist eine kleine Anweisung, die Ihre Webseite an Browser schickt. Sie listet auf, welche Quellen Skripte, Stile, Bilder und andere Inhalte für Ihre Seite liefern dürfen. Der Browser weigert sich anschließend, Inhalte aus nicht gelisteten Quellen zu laden.

Ihre Seite schickt diese Anweisung derzeit nicht. Der Browser-Default lautet dann “Inhalte aus jeder Quelle erlaubt”, und genau deshalb sind bestimmte Webseiten-Angriffe so schädlich.

Warum das wichtig ist

Ein verbreitetes Angriffsmuster ist Cross-Site Scripting (XSS, siehe XSS-Artikel): ein Angreifer schafft es, dass Ihre Seite einen von ihm kontrollierten Inhalt (etwa eine Suchanfrage, einen Kommentar oder ein Profilfeld) so darstellt, dass der Browser ihn als Code statt als Text ausführt. Ohne CSP kann dieser Code:

  • Alles auslesen, worauf der Browser im Kontext Ihrer Seite Zugriff hat, inklusive Cookies und Formularinhalten.
  • All das an einen Server des Angreifers schicken.
  • Weiteren Angriffs-Code aus beliebigen externen Quellen nachladen.
  • Anzeigen verändern, z. B. Ihr echtes Login-Formular durch ein gefälschtes ersetzen.

Eine gut eingestellte CSP macht denselben Bug deutlich kleiner. Der Schadcode kann keine Helfer von außen nachladen, keine Daten an externe Server senden und keine getarnten Eingabe-Oberflächen einblenden. Der Bug bleibt, sein Schaden sinkt deutlich.

CSP gibt Ihnen außerdem zusätzliche Kontrolle über Drittanbieter-Werkzeuge, die Sie nicht voll geprüft haben. Versucht ein Marketing-Widget oder ein Chat-Tool etwas Neues nachzuladen, blockt CSP es (und meldet es Ihnen), statt es stillschweigend zuzulassen.

So beheben Sie das

Eine vollständige CSP für eine reale Seite braucht etwas Feinarbeit. Moderne Webseiten nutzen viele Inline-Skripte und Drittanbieter-Tools, das alles vollständig zu listen erfordert Sorgfalt. Empfohlener Weg: ein dreistufiger Rollout, der unterwegs nichts bricht.

Stufe 1: Beobachten (Woche 0)

CSP im Report-only-Modus deployen. Der Browser meldet Verstöße an Ihren Server, blockt aber noch nichts:

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' 'unsafe-inline';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data:;
  connect-src 'self';
  frame-ancestors 'none';
  report-uri /csp-report;

Eine Woche die Berichte beobachten. Jeder Verstoß zeigt einen Drittanbieter-Dienst, ein Inline-Skript oder ein Embed, das Sie sonst übersehen hätten.

Stufe 2: Verschärfen (Woche 2)

Die 'unsafe-inline'-Erlaubnis für Skripte durch einen sichereren Mechanismus ersetzen: eine pro Request einmalige Zufallszeichenkette (“Nonce”), die jedem legitimen Inline-Skript zugewiesen wird. Die meisten modernen Frameworks (Next.js, Rails 7+, Django, Laravel) erzeugen sie automatisch. Tatsächlich genutzte Drittanbieter-Hosts in die Allow-Liste aufnehmen.

Stufe 3: Erzwingen (Woche 3)

Header-Namen von Content-Security-Policy-Report-Only auf Content-Security-Policy ändern. Die Policy ist jetzt aktiv.

Sofort umsetzbar, ohne vollen Rollout

Ist eine vollständige CSP gerade zu viel Aufwand, decken zwei schmalere Header je einen relevanten Bereich ab:

  • frame-ancestors 'none' (oder 'self') verhindert, dass Ihre Seite in einem fremden iframe geladen wird (siehe X-Frame-Options-Artikel).
  • default-src 'self' blockt die meisten Mixed-Content-Nachlader für Seiten, die keine Drittanbieter-Inhalte einbinden.

Mehr dazu