Content Security Policy (CSP) in Joomla konfigurieren
CSP in Joomla aktivieren — über den dedizierten CSP-Tab im Built-in HTTP Headers Plugin oder .htaccess-Fallback. Mit Report-Only-Modus, Verifizierung und Joomla-spezifischen Fehlerlösungen.
Content Security Policy (CSP) in Joomla
Content Security Policy (CSP) ist der wichtigste HTTP-Security-Header gegen Cross-Site Scripting (XSS) und Daten-Injection-Angriffe. CSP definiert, welche Ressourcen ein Browser laden darf — Scripts, Styles, Bilder, Fonts und Frames. Mit 35 von 166 Punkten ist CSP der einflussreichste Header im Wolf-Agents Web Security Check. Ohne CSP ist eine Note besser als C praktisch unmöglich.
Joomla 4+ bietet im Built-in HTTP Headers Plugin (System → Plugins → System - HTTP Headers) einen dedizierten CSP-Tab mit separaten Feldern für Report-Only und Enforcement. Dort konfigurieren Sie jede CSP-Direktive einzeln über GUI-Felder — default-src, script-src, style-src, img-src und weitere. Die größte Herausforderung bei Joomla ist die Kompatibilität mit dem JCE Editor (nutzt Inline-Styles extensiv), dem Standard-Template Cassiopeia (lädt externe Google Fonts) und Drittanbieter-Extensions, die externe Scripts einbinden.
Der Wolf-Agents Web Security Check analysiert
Ihre CSP im Detail und zeigt blockierte Ressourcen, fehlende Direktiven und unsichere
Werte wie unsafe-inline. Über das
Web Scan Monitoring werden Sie automatisch
per E-Mail benachrichtigt, wenn sich CSP-Konfigurationen nach einem Joomla-Update
oder Extension-Installation unbeabsichtigt ändern.
Content Security Policy (CSP)-Implementierung in Joomla
Das HTTP Headers Plugin bietet einen dedizierten CSP-Tab mit zwei Modi: Report-Only (zum Testen, Browser meldet Violations aber blockiert nicht) und Enforcement (aktive Blockierung nicht erlaubter Ressourcen). Starten Sie immer mit Report-Only und prüfen Sie die Browser-Konsole 1-2 Wochen lang auf Violations. Jede Direktive hat ein eigenes GUI-Feld — Sie konfigurieren default-src, script-src, style-src, img-src, font-src, object-src, base-uri, form-action und frame-ancestors einzeln, ohne eine Zeile Code zu schreiben.
# HTTP Headers Plugin → Tab: Content Security Policy
# (Built-in seit Joomla 4.0 — eigener Tab im Plugin)
Content Security Policy: Aktiviert
Modus: Report-Only (zuerst!)
# Direktiven einzeln konfigurieren:
default-src: 'self'
script-src: 'self'
style-src: 'self' 'unsafe-inline'
img-src: 'self' data: https:
font-src: 'self'
object-src: 'none'
base-uri: 'self'
form-action: 'self'
frame-ancestors: 'none'
# Nach 1-2 Wochen ohne Violations:
# Modus auf "Enforcement" umstellen# .htaccess — CSP-Fallback (ohne Plugin-GUI)
# Zuerst Report-Only zum Testen:
<IfModule mod_headers.c>
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'"
</IfModule>
# Nach Test-Phase: Report-Only durch aktive Policy ersetzen
# Header always set Content-Security-Policy "..."Eine falsch konfigurierte CSP kann Ihre gesamte Joomla-Website unbenutzbar machen — Formulare funktionieren nicht, Bilder fehlen, das Backend ist kaputt. Nutzen Sie immer zuerst den Report-Only-Modus des HTTP Headers Plugins und prüfen Sie die Browser-Konsole auf Violations, bevor Sie auf Enforcement umschalten.
Verifizierung
Nach der Konfiguration im HTTP Headers Plugin leeren Sie den Joomla-Cache und prüfen den Header per curl. Testen Sie auf verschiedenen Seitentypen — Startseite, Beiträge mit JCE-Inhalten, Kontaktformulare und den Admin-Bereich. Öffnen Sie die Browser-DevTools (F12 → Console) und filtern Sie nach "Refused to" — jede CSP-Violation erscheint dort als Warnung oder Fehler.
# 1. Joomla-Cache leeren
php cli/joomla.php cache:clean
# 2. CSP-Header prüfen
curl -sI https://ihre-domain.de | grep -i content-security-policy
# Erwartete Ausgabe (Report-Only-Phase):
# content-security-policy-report-only: default-src 'self'; ...
# 3. Browser-Konsole auf CSP-Violations prüfen
# DevTools → Console → nach "Refused to" filtern
# 4. Verschiedene Seitentypen testen
curl -sI https://ihre-domain.de/beispiel-beitrag | grep -i content-security
curl -sI https://ihre-domain.de/administrator | grep -i content-securityHäufige Fehler bei Content Security Policy (CSP) in Joomla
JCE Editor Inline-Styles werden durch CSP blockiert
Der JCE Editor nutzt extensiv Inline-Styles für Formatierungen in Beiträgen. Fügen Sie 'unsafe-inline' zu style-src hinzu. Für script-src verwenden Sie Nonces oder Hashes — niemals 'unsafe-inline' für Scripts, da dies den XSS-Schutz von CSP komplett aushebelt.
HTTP Headers Plugin deaktiviert — kein CSP-Header gesetzt
Prüfen Sie unter System → Plugins, ob das System - HTTP Headers Plugin aktiviert ist und der CSP-Tab auf "Aktiviert" steht. Ohne aktives Plugin werden keine CSP-Header gesendet. Stellen Sie sicher, dass keine Sicherheits-Extension (RSFirewall, Admin Tools) einen eigenen, möglicherweise schwächeren CSP setzt.
Cassiopeia-Template lädt externe Google Fonts — CSP blockiert
Das Standard-Template Cassiopeia und viele Custom Templates laden Google Fonts von externen Domains. Fügen Sie fonts.googleapis.com zu style-src und fonts.gstatic.com zu font-src hinzu. Besser für DSGVO: Fonts lokal hosten und externe Quellen komplett vermeiden.
Core-Update oder Extension-Installation ändert CSP-Anforderungen
Neue Extensions oder Template-Updates können zusätzliche externe Ressourcen laden, die von der bestehenden CSP blockiert werden. Prüfen Sie nach jedem Update die Browser-Konsole auf neue CSP-Violations und passen Sie die Direktiven im HTTP Headers Plugin entsprechend an.
Compliance-Relevanz
Content Security Policy ist nicht nur technische Best Practice gegen XSS, sondern erfüllt konkrete Anforderungen aus mehreren Compliance-Frameworks. Besonders PCI DSS 4.0 schreibt CSP oder SRI für Payment-Pages explizit vor.
Wie steht Ihre Domain bei Content Security Policy (CSP)?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.