04.06.2026 | Lesezeit: ca. 5 Minuten

Content-Security-Policy — der Filter im Browser

Fremder Code kommt nicht durch

Content-Security-Policy — der Filter im Browser — Hero-Bild

Eine Webseite lädt selten nur eigene Dateien. Schriften kommen von einem Anbieter, das Kontaktformular bindet einen Spam-Schutz ein, eine Karte stammt von einem Kartendienst, dazu vielleicht ein Statistik-Werkzeug. Der Browser führt all das aus, ohne nachzufragen, woher es kommt.

Genau diese Gutgläubigkeit nutzen Angreifer aus. Schaffen sie es, eine einzige Zeile fremden Skript-Code in Deine Seite zu schmuggeln, läuft die im Browser jedes Besuchers mit. Eine Content-Security-Policy zieht hier eine Grenze, indem sie dem Browser eine Gästeliste vorlegt.

Was eine Content-Security-Policy macht

Eine Content-Security-Policy ist eine Regelliste, die Dein Server zusammen mit der Seite ausliefert. Sie nennt dem Browser, von welchen Quellen er Skripte, Bilder, Schriften oder Stylesheets überhaupt annehmen darf. Alles, was nicht auf der Liste steht, lädt der Browser nicht.

Du kannst Dir das wie eine Einlasskontrolle vorstellen. Der Browser fragt vor jedem geladenen Element, ob die Herkunft erlaubt ist. Steht der Absender nicht auf der Liste, bleibt die Tür zu, und der fremde Code wird verworfen, bevor er etwas anrichtet.

Das Schöne daran ist die Richtung der Verteidigung. Die Policy schützt den Browser des Besuchers, also die Stelle, an der fremder Code Schaden anrichtet. Selbst wenn ein Angreifer schon Code in Deine Seite eingeschleust hat, verhindert eine gut gesetzte Regel, dass dieser Code nach Hause telefoniert oder Daten abgreift.

Was sie gegen XSS und Code-Injection leistet

Die häufigste Angriffsart, gegen die eine Policy wirkt, heißt Cross-Site-Scripting, kurz XSS. Dabei landet fremder Skript-Code über ein Eingabefeld, eine Kommentarfunktion oder eine manipulierte Adresse in Deiner Seite und wird beim nächsten Aufruf mit ausgeführt.

Eine Content-Security-Policy entzieht solchem Code den Boden. Wenn die Regel sagt, dass Skripte nur von Deiner eigenen Domain laufen dürfen, ignoriert der Browser eingeschleuste Schnipsel von anderswo. Der Angriff läuft ins Leere, obwohl die Lücke im Formular vielleicht noch existiert. Sie ergänzt damit andere Security-Header, die der Browser im Hintergrund auswertet.

Sauberer Programmcode bleibt die erste Pflicht. Die Policy fängt zusätzlich das ab, was trotzdem durchrutscht. Diese zweite Verteidigungslinie ist der Grund, warum große Plattformen wie Banken oder Shops schon lange auf das Verfahren setzen.

Erst mitlesen, dann scharf schalten

Die größte Sorge bei der Einführung ist berechtigt. Eine zu strenge Regel blockiert versehentlich eigene, harmlose Skripte, und plötzlich fehlt die Karte oder das Formular reagiert nicht mehr. Deshalb gibt es einen sicheren Einstieg über den sogenannten Report-Only-Modus.

In diesem Modus blockiert der Browser noch nichts. Er meldet nur, was er nach den geplanten Regeln blockieren würde. Du sammelst diese Meldungen ein paar Tage lang ein und siehst genau, welche Dienste Deine Seite wirklich braucht, bevor irgendetwas kaputtgeht.

Erst wenn die Meldungen ruhig bleiben und keine echten Inhalte mehr darunter sind, schaltest Du die Regel scharf. Dieser zweistufige Weg nimmt der Content-Security-Policy ihren Schrecken und macht sie auch für kleine Seiten beherrschbar.

Typische Stolpersteine bei eingebetteten Diensten

Die meisten Probleme entstehen an den Stellen, wo Deine Seite Fremdes einbindet. Jeder externe Dienst braucht eine eigene Erlaubnis, sonst sperrt die Policy ihn aus. Das betrifft vor allem die üblichen Verdächtigen.

  • Schriften und Karten: Externe Schriftdienste und eingebettete Karten laden von fremden Domains und müssen ausdrücklich freigegeben werden.
  • Statistik und Spam-Schutz: Werkzeuge zur Besucherzählung oder zum Schutz von Formularen ziehen oft Skripte von mehreren Servern nach.
  • Eingebettete Videos: Ein Video von einer fremden Plattform läuft in einem eigenen Rahmen, der separat erlaubt sein will.
  • Inline-Skripte im Seitenquelltext: Direkt in die Seite geschriebene Skripte gelten als unsicher und werden von einer strengen Policy zuerst geblockt.

Gerade der letzte Punkt erwischt viele Baukasten- und Plugin-Seiten, weil dort Skripte oft mitten im Quelltext stehen. Hier zeigt der Report-Only-Modus seinen Wert, denn er macht jede dieser Stellen sichtbar, bevor sie zum Ausfall führt.

Warum sich der Aufwand auch für kleine Seiten lohnt

Eine Content-Security-Policy ist eine der wenigen Schutzmaßnahmen, die im Hintergrund wirkt und Deine Besucher nie stört. Sie verlangt kein zweites Passwort, kein Einverständnis und keinen sichtbaren Schritt. Der Schutz läuft einfach mit.

Für eine kleine Firmenseite oder einen Blog ist das ein günstiges Sicherheitsnetz. Du investierst einmalig etwas Zeit in die Einrichtung und gewinnst dauerhaft eine Schicht, die selbst bei einer übersehenen Lücke noch greift. Sie reiht sich neben andere stille Schutzmaßnahmen wie erzwungenes HTTPS über HSTS, die der Browser im Hintergrund auswertet.

Wer eine Seite ohnehin von einer Agentur betreuen lässt, fragt am besten direkt nach, ob eine solche Policy gesetzt ist. Es ist eine kleine Frage mit großer Wirkung, und die Antwort verrät viel über die Sorgfalt hinter Deinem Auftritt.

Wer die Policy bei Dir einrichtet

Die Regeln landen in der Server-Konfiguration oder werden vom Content-Management-System ausgeliefert. Beides ist Sache der Person, die Deine technische Umgebung betreut, also Deiner Agentur oder Deines Hosters.

Du musst die Regeln nicht selbst schreiben, aber Du solltest wissen, wonach Du fragst. Bitte um eine Policy, die zuerst im Report-Only-Modus läuft, und lass Dir bestätigen, dass alle eingebundenen Dienste vorher geprüft wurden. Damit vermeidest Du, dass die Seite nach dem Scharfschalten an einer Stelle stockt.

Wenn Deine Seite bereits auf sicheres Hosting und Sicherheitsmaßnahmen vor dem Browser setzt, ergänzt die Policy diese sinnvoll. Ein vorgelagerter Filter prüft Anfragen, bevor sie den Server erreichen, während die Content-Security-Policy direkt im Browser jedes Besuchers arbeitet. Beide Ebenen zusammen schließen unterschiedliche Lücken.

Fazit

Eine Content-Security-Policy gibt dem Browser eine klare Anweisung, welchem Code er trauen darf. Sie kostet wenig, läuft unsichtbar mit und fängt genau die Angriffe ab, die durch eine übersehene Lücke schlüpfen.

Der sichere Weg dorthin führt über den Report-Only-Modus, der erst zeigt und dann sperrt. Sprich Deine Agentur darauf an, lass die Regeln in Ruhe einfahren, und Du hast eine stille Schutzschicht gewonnen, die Deinen Besuchern nie auffällt.