Katalog
concept#Sicherheit#Architektur#Softwareentwicklung

Content Security Policy (CSP)

Content Security Policy (CSP) ist ein browserseitiger Mechanismus zur Einschränkung erlaubter Ressourcenquellen. CSP hilft, Cross-Site-Scripting und andere Injektionsangriffe zu reduzieren, indem Entwickler erlaubte Quellen für Skripte, Styles, Bilder und Frames deklarieren.

Content Security Policy (CSP) ist ein browserseitiger Sicherheitsstandard, mit dem Webanwendungen erlaubte Quellen für Inhalte wie Skripte, Styles, Bilder und Frames deklarieren.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

Webserver: Nginx, Apache (Header-Deployment)CDN-Konfigurationen für erlaubte QuellenSIEM/Logging-Systeme für CSP-Reports

Prinzipien & Ziele

Prinzip der geringsten Rechte für RessourcenquellenSchrittweises Einführen (report-only → enforcement)Transparenz durch Reporting für Observability
Umsetzung
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Übermäßig restriktive Regeln führen zu Ausfällen
  • Unzureichende Report-Verarbeitung verhindert Erkenntnisse
  • Falsche Annahmen über Drittanbieter-Sicherheit
  • Beginne mit report-only Mode und analysiere echte Verletzungen.
  • Verwende Nonces oder Hashes statt breiter 'unsafe-inline'-Regeln.
  • Integriere Reports in bestehende Monitoring-Tools.

I/O & Ressourcen

  • Inventar aller eingebundenen Skripte, Styles, Bilder und Frames
  • Liste autorisierter Domains und CDNs
  • Deploy-Mechanismus für HTTP-Header oder Meta-Tags
  • CSP-Header/Meta-Tag-Konfiguration
  • Aggregierte Reports über Policy-Verletzungen
  • Aktualisierte Richtlinien und Dokumentation

Beschreibung

Content Security Policy (CSP) ist ein browserseitiger Sicherheitsstandard, mit dem Webanwendungen erlaubte Quellen für Inhalte wie Skripte, Styles, Bilder und Frames deklarieren. Er reduziert Cross-Site-Scripting- und Injection-Risiken, indem das Laden und Ausführen von Ressourcen eingeschränkt wird. CSP erfordert sorgfältiges Policy-Design, Reporting und schrittweises Rollout.

✔

  • Reduziert XSS- und Script-Injection-Risiken
  • Ermöglicht granularen Schutz gegen unsichere Drittressourcen
  • Bietet Reporting zur Überwachung und forensischen Analyse

✖

  • Nicht alle Browser unterstützen alle CSP-Level vollständig
  • Fehlerhafte Policies können Seitenfunktionen brechen
  • Schützt nicht gegen bereits kompromittierte erlaubte Ressourcen

  • Anzahl CSP-Verletzungen

    Anzahl der pro Zeitraum gemeldeten Policy-Verletzungen; Indikator für Fehlkonfiguration oder Angriffsversuche.

  • Fehlerrate nach Policy-Einführung

    Anteil der Nutzer-Sessions, die durch CSP-Verstöße funktional beeinträchtigt sind.

  • Zeit bis zur Behebung einer CSP-Verletzung

    Durchschnittliche Zeit vom Eingang eines Reports bis zur Umsetzung einer Korrekturmaßnahme.

E-Commerce-Plattform reduziert XSS-Vorfälle

Ein Online-Shop führte CSP report-only ein, sammelte Verletzungen und aktivierte nach Iteration eine restriktive Policy. Anzahl gemeldeter XSS-Fälle sank signifikant.

SPA mit CDN-Integration

Single-Page-App erlaubte explizit nur bestimmte CDNs und nonces für dynamische Skripte, dadurch konnten unerwartete Third-Party-Ausführungen verhindert werden.

Continuous Monitoring über CSP-Reports

Ein Team integrierte CSP-Reports in ihr SIEM und konnte frühzeitig fehlerhafte Bibliotheks-Updates und ungewöhnliche Request-Muster erkennen.

1

Inventarisierung von Ressourcen und Drittanbietern durchführen.

2

Report-only CSP konfigurieren und Reports sammeln.

3

Policy iterativ anpassen, Tests in Staging durchführen.

4

Enforcement aktivieren und Monitoring etablieren.

5

Regelmäßige Reviews und Policy-Updates planen.

⚠️ Technische Schulden & Engpässe

  • Legacy-Code mit Inline-Skripten, der Nonces nicht unterstützt.
  • Fehlende automatisierte Tests für Policy-Änderungen.
  • Keine zentrale Infrastruktur zur Verarbeitung von CSP-Reports.
Legacy-Assets mit Inline-SkriptenUnvollständige Inventarisierung externer AbhängigkeitenBegrenzte Observability für CSP-Reports
  • Setzen von 'unsafe-inline' für alle Seiten zur schnellen Befriedigung von Funktionalität.
  • Verwendung von zu breiten Wildcards ('*') für kritische Direktiven.
  • Deploy einer Enforcement-Policy ohne vorherige Staging-Tests.
  • Vergessen, CSP-Reports zu verarbeiten und zu überwachen.
  • Annahme, dass CSP alle Web-Sicherheitsprobleme löst.
  • Nicht-Berücksichtigung von Subresource-Integrationen (Worker, Frames).
Web-Sicherheitsprinzipien (XSS, CSP)Front-end-Architektur und Abhängigkeits-ManagementLogging/Observability und SIEM-Grundlagen
Verfügbarkeit kritischer DiensteIntegrationsbedarf mit DrittanbieternKonformität und Auditierbarkeit
  • • Browserkompatibilität unterschiedlicher CSP-Level
  • • Legacy-Code, der keine Nonces oder Hashes unterstützt
  • • Geschäftlich geforderte Drittanbieter-Integrationen