🛡️
Beveiliging

Content Security Policy (CSP) für deine Website einrichten

📅 8 Oktober 2026 ✏️ 8 Oktober 2026 ⏱ 4 min leestijd

Erfahre Schritt für Schritt, wie du eine Content Security Policy in Plesk oder über .htaccess konfigurierst, um deine Website vor XSS-Angriffen zu schützen.

Eine Content Security Policy (CSP) ist ein HTTP-Header, mit dem du festlegst, welche Ressourcen ein Browser auf deiner Website laden darf, wie Skripte, Stylesheets und Bilder. Damit verringerst du das Risiko von Cross-Site-Scripting (XSS) und anderen Injection-Angriffen erheblich. In diesem Artikel liest du, was CSP genau macht, wie du den Header über .htaccess oder Plesk einstellst und wie du häufige Fehler vermeidest.

Was ist eine Content Security Policy

CSP ist eine Sicherheitsebene, die Browsern mitteilt, von welchen Domains sie Inhalte laden dürfen. Ohne CSP kann ein Angreifer über eine Schwachstelle in deiner Website schädliches JavaScript einschleusen, das dann ohne Einschränkungen ausgeführt wird. Mit einer gut eingerichteten Policy blockiert der Browser alles, was nicht explizit erlaubt ist, selbst wenn der bösartige Code bereits im HTML steht.

Die Policy wird als HTTP-Response-Header Content-Security-Policy mitgesendet. Du kannst sie auf Serverebene, über ein Meta-Tag im HTML oder über dein CMS einstellen. Für die meisten Websites ist die Einrichtung auf Serverebene am sichersten, da sie nicht durch ein kompromittiertes Skript überschrieben werden kann.

BrowserCSP-HeaderServer

CSP-Direktiven und Beispiele

Eine CSP besteht aus Direktiven, die angeben, welcher Content-Typ aus welcher Quelle kommen darf. Die wichtigsten sind:

  • default-src: Standardregel für alle Content-Typen, wenn keine spezifischere Direktive vorhanden ist.
  • script-src: bestimmt, woher JavaScript kommen darf.
  • style-src: bestimmt erlaubte Quellen für CSS.
  • img-src: regelt Bilder.
  • font-src: regelt Schriftarten.
  • connect-src: regelt AJAX-, WebSocket- und Fetch-Verbindungen.
  • frame-ancestors: bestimmt, welche Sites deine Seite in einem iframe einbetten dürfen.

Ein einfaches Beispiel, das nur Inhalte von deiner eigenen Domain erlaubt, mit Ausnahme für Google Fonts:

Content-Security-Policy: default-src 'self'; style-src 'self' fonts.googleapis.com; font-src fonts.gstatic.com;

💡 Tipp: Beginne immer mit einer Report-Only-Policy (Content-Security-Policy-Report-Only), bevor du den eigentlichen Header aktivierst. So siehst du, welche Quellen blockiert werden, ohne dass deine Website kaputt geht.

CSP auf deinem Server einrichten

Du kannst den CSP-Header auf verschiedene Arten hinzufügen, abhängig von deiner Serverkonfiguration.

1

Über .htaccess

Füge die folgende Zeile zur .htaccess-Datei im Stammverzeichnis deiner Website hinzu: Header set Content-Security-Policy "default-src 'self';". Diese Methode funktioniert direkt auf Apache- und LiteSpeed-Servern.

2

Über Plesk

Melde dich bei Plesk an, gehe zu deiner Domain und öffne Apache- & nginx-Einstellungen. Dort kannst du unter „Zusätzliche Direktiven“ den CSP-Header manuell hinzufügen, ohne deine .htaccess bearbeiten zu müssen.

3

Über ein Meta-Tag

Wenn du keine Servereinstellungen anpassen kannst, kannst du die Policy auch im HTML setzen: <meta http-equiv="Content-Security-Policy" content="default-src 'self';">. Beachte: Damit kannst du keine frame-ancestors oder report-uri einstellen.

4

Schrittweise pro Content-Typ erweitern

Füge Schritt für Schritt zusätzliche Direktiven für Skripte, Stile, Bilder und Schriftarten hinzu, bis die gesamte Funktionalität deiner Website wieder funktioniert, ohne dass du die Policy zu weit öffnen musst.

Testen und häufige Fehler

Teste deine Policy immer in der Browserkonsole; dort siehst du sofort, welche Quellen mit einer klaren Fehlermeldung blockiert werden. Häufige Fehler sind:

  • Die Verwendung von unsafe-inline für Skripte, wodurch der Schutz vor XSS größtenteils zunichtegemacht wird.
  • Vergessen, dass externe Dienste wie Analytics, Chat-Widgets oder Werbenetzwerke ebenfalls explizit erlaubt werden müssen.
  • Keine Berücksichtigung von Subdomains, die eigene Regeln benötigen.
  • Die Policy direkt live schalten, ohne vorher mit Report-Only zu testen.

Überprüfe auch, ob E-Mail-bezogene Formulare und eingebettete Inhalte, wie die über geschäftliche E-Mail-Widgets oder Kontaktformulare, nach der Einrichtung der Policy noch korrekt funktionieren. Kommst du nicht weiter, konsultiere die Wissensdatenbank für weitere Konfigurationsbeispiele oder wende dich an den Support.

Häufig gestellte Fragen

Bricht eine CSP meine Website sofort?

Nicht, wenn du zuerst mit Report-Only testest. Eine falsch eingestellte Policy kann Skripte oder Stile blockieren, überprüfe daher immer die Browserkonsole, bevor du live gehst.

Funktioniert CSP zusammen mit einem CDN?

Ja, füge die Domain deines CDN zu den relevanten Direktiven hinzu, zum Beispiel script-src oder style-src, damit Dateien von dieser Quelle erlaubt werden.

Ist CSP für eine gute Sicherheitsbewertung verpflichtend?

Nicht verpflichtend, aber empfehlenswert. Es verringert die Auswirkungen von XSS-Schwachstellen und wird von Sicherheitsscannern oft positiv bewertet.

Kann ich CSP mit kostenlosem SSL kombinieren?

Ja, CSP und SSL arbeiten unabhängig voneinander, ergänzen sich aber gut: SSL sichert den Transport, CSP beschränkt, welche Inhalte geladen werden dürfen.

Muss ich CSP für meinen Domainnamen oder pro Subdomain einrichten?

Pro Subdomain separat, da jede Subdomain ihre eigenen Header und Konfiguration haben kann. Verwaltest du mehrere Domainnamen, richte für jede Domain eine passende Policy ein.

Fazit

Eine Content Security Policy ist eine wirkungsvolle, aber präzise Methode, um deine Website vor XSS und unerwünschten Inhalten zu schützen. Beginne mit Report-Only, baue die Policy Schritt für Schritt pro Direktive auf und teste gründlich, bevor du live gehst. So verhinderst du, dass legitime Funktionalität blockiert wird.

Webhosting ansehen →

Was dit artikel nuttig?