Content Security Policy (CSP) erklärt: Websicherheit für Entwickler

Content Security Policy (CSP) zählt zu den wichtigsten, aber oft unterschätzten Sicherheitsmechanismen im Frontend-Bereich.

Doch was verbirgt sich hinter diesem Konzept?

CSP ist eine Sicherheitsrichtlinie, die Sie über HTTP-Header an den Browser senden. Sie definiert, welche Ressourcen – etwa JavaScript, CSS oder Bilder – geladen werden dürfen und welche blockiert werden müssen.

Stellen Sie sich vor, der Browser erhält eine Liste vertrauenswürdiger Quellen. Jedes Mal, wenn eine Ressource angefordert wird, prüft der Browser, ob die Quelle auf dieser Liste steht. Ist das nicht der Fall, wird die Anfrage abgelehnt.

Auf diese Weise lassen sich schädliche Skripte oder manipulierte Inhalte zuverlässig blockieren – bevor sie Schaden anrichten können.

Wie funktioniert Content Security Policy?

CSP wird als HTTP-Antwortheader übertragen und enthält eine klare Anweisung für den Browser:

• Welche Domains oder Quellen sind für die Ausführung von Skripten, Stilen oder Medieninhalten zulässig?
• Welche Direktiven wie script-src, style-src oder img-src steuern den Zugriff auf bestimmte Ressourcentypen?
• Welche Sicherheitsmechanismen wie 'self', 'unsafe-inline' oder 'unsafe-eval' sind erlaubt?

Ein einfaches Beispiel verdeutlicht die Funktionsweise:

Content-Security-Policy: default-src 'self'; script-src 'self' 

Hier bedeutet default-src 'self', dass alle Ressourcen standardmäßig nur von der eigenen Domain geladen werden dürfen. Die zusätzliche Direktive script-src erlaubt JavaScript zusätzlich von `

Jeder Versuch, Skripte von einer nicht gelisteten Quelle auszuführen, wird vom Browser unterbunden – selbst wenn ein Angreifer schadhaften Code einschleusen konnte.

Welche Sicherheitsrisiken lassen sich mit CSP mindern?

Obwohl CSP primär gegen Cross-Site Scripting (XSS) entwickelt wurde, bietet es Schutz vor weiteren Bedrohungen:

• Clickjacking: Verhindert, dass Ihre Seite in unsichtbaren iframes eingebettet wird.
• Drittanbieter-Ressourcen: Blockiert den Zugriff auf externe Skripte oder Stylesheets, die nicht explizit erlaubt sind.
• Formular-Missbrauch: Beschränkt, wohin Formulardaten gesendet werden dürfen.
• Manipulierte Weiterleitungen: Kontrolliert, welche URLs für Weiterleitungen akzeptiert werden.
• Inhaltsdiebstahl: Schützt vor dem unautorisierten Einbinden von Bildern oder Medieninhalten.

Durch die Kombination dieser Maßnahmen entsteht eine mehrschichtige Sicherheitsbarriere, die Angriffe bereits im Ansatz unterbindet.

CSP in der Praxis: Ein Beispiel aus dem Alltag

Die Implementierung von CSP erfordert zwar etwas Aufwand, zahlt sich aber langfristig aus.

Nehmen wir an, Sie entwickeln eine Webanwendung mit folgenden Abhängigkeiten:

• Eigene JavaScript-Dateien auf Ihrer Domain
• Ein externes CSS-Framework von `
• Fonts von `
• Bilder von `

Eine passende CSP könnte so aussehen:

Content-Security-Policy: 
  default-src 'self'; 
  script-src 'self' 
  style-src 'self'  'unsafe-inline';
  img-src 'self' 
  font-src 'self' 

• `script-src` erlaubt nur Ihre eigenen Skripte und das externe Framework.
• `style-src` erlaubt zusätzlich Inline-Stile, was in manchen Fällen notwendig ist.
• `img-src` beschränkt Bilder auf Ihre Domain und einen vertrauenswürdigen CDN-Anbieter.

Wichtig: Je strenger die Richtlinie, desto sicherer ist Ihre Anwendung. Allerdings kann eine zu restriktive Konfiguration auch die Funktionalität einschränken.

Herausforderungen bei der CSP-Implementierung

Die größte Hürde liegt darin, alle benötigten Ressourcen zu identifizieren und in die Richtlinie aufzunehmen. Häufig werden folgende Probleme beobachtet:

• Inline-Skripte oder -Styles: Viele ältere Anwendungen nutzen onclick-Attribute oder <style>-Tags direkt im HTML. Diese müssen entweder entfernt oder über unsafe-inline erlaubt werden – was die Sicherheit verringert.
• Externe Bibliotheken: Third-Party-Bibliotheken wie jQuery oder React müssen in script-src eingetragen werden.
• Dynamische Inhalte: Skripte, die zur Laufzeit generiert werden, erfordern besondere Aufmerksamkeit.
• Reporting: Ohne Überwachung bleibt unklar, welche Ressourcen blockiert werden. Tools wie Report-To oder report-uri helfen, Angriffsversuche zu erkennen.

Frameworks wie Next.js oder Angular bieten integrierte Unterstützung für CSP. Dennoch empfiehlt es sich, die Richtlinien regelmäßig zu überprüfen und anzupassen.

Fazit: CSP als Grundpfeiler der Websicherheit

Content Security Policy ist kein Allheilmittel, aber ein mächtiges Werkzeug, um die Sicherheitslage Ihrer Webanwendung deutlich zu verbessern.

Durch die gezielte Einschränkung von Ressourcenquellen lässt sich das Risiko von XSS, Datenlecks und anderen Angriffen erheblich reduzieren.

Die Implementierung erfordert zwar etwas Einarbeitungszeit, doch die Investition lohnt sich – besonders in Zeiten zunehmender Cyberbedrohungen.

In den kommenden Artikeln dieser Reihe werden wir weitere Frontend-Sicherheitsthemen vertiefen, darunter Authentifizierung, API-Sicherheit und Schutz vor Datenmanipulationen. Bleiben Sie dran.