Content-Security-Policy (CSP): Fehlenden Header richtig einrichten
Ohne Content-Security-Policy-Header kann eingeschleuster Schadcode ungehindert im Browser laufen. So erkennen Sie die Lücke und richten CSP korrekt ein.
Inhaltsverzeichnis
Fehlt der Content-Security-Policy-Header, hat der Browser keine Vorgabe, welche Skripte und Ressourcen auf einer Seite vertrauenswürdig sind — er lädt und führt praktisch alles aus, was im HTML steht oder nachträglich eingeschleust wird. EverAudit meldet das als Sicherheitsbefund in der Kategorie „Security-Header".
Was ist das Problem?#
Ohne Content-Security-Policy-Header definiert eine Website keine erlaubten Quellen für Skripte, Styles und andere aktive Inhalte. Der Browser vertraut dann jedem Code, der im Dokument steht — unabhängig davon, ob er vom Betreiber stammt oder eingeschleust wurde. Das öffnet eine zusätzliche Angriffsfläche.
Technisch ist CSP ein HTTP-Response-Header, den der Server bei jeder Antwort mitschickt, zum Beispiel:
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none'Die Direktive default-src 'self' erlaubt standardmäßig nur Inhalte von der eigenen Domain, script-src erlaubt zusätzlich ein vertrauenswürdiges CDN, und object-src 'none' verbietet veraltete Plugin-Einbettungen wie Flash oder Java-Applets vollständig.
Warum prüft EverAudit das?#
EverAudit prüft bei jeder gecrawlten Seite die tatsächlichen HTTP-Response-Header und meldet, wenn kein Content-Security-Policy-Header gesetzt ist. Der Check läuft unabhängig vom eingesetzten CMS oder Framework, da er direkt am Server-Ausgang ansetzt, nicht am HTML selbst.
Ein fehlender CSP-Header betrifft in der Regel die gesamte Domain und nicht nur eine einzelne Seite, weil er meist zentral am Webserver, CDN oder Reverse-Proxy gesetzt wird. EverAudit ordnet den Befund deshalb in die höchste Priorität ein, da er ein grundlegendes Schutzschild betrifft, das sonst komplett fehlt.
Welche Auswirkung hat das?#
Ohne CSP verpufft eine zentrale Verteidigungslinie gegen Cross-Site-Scripting: Eingeschleuster Code läuft im Browser der Besucher wie normaler Website-Code und kann Formulardaten, Session-Cookies oder Zahlungsinformationen abgreifen. Für Nutzer ist das Risiko unsichtbar, bis ein Missbrauch auffällt.
Konkret bedeutet das: Gelingt es Angreifern, über eine Sicherheitslücke Fremdcode in eine Seite einzuschleusen — etwa über einen kompromittierten Kommentar, ein verwundbares Plugin oder eine ungeprüfte Nutzereingabe —, wird dieser Code ohne CSP genauso ausgeführt wie der eigene. Mit einer restriktiven Policy würde der Browser den Fremdcode blockieren, weil seine Quelle nicht auf der erlaubten Liste steht. Für Besucher bedeutet das im Ernstfall gestohlene Zugangsdaten oder manipulierte Formulare; für den Seitenbetreiber ein handfestes Vertrauensproblem.
Wie beheben Sie das?#
Eine Content-Security-Policy führen Sie schrittweise ein, damit bestehende Funktionen nicht versehentlich blockiert werden. Beginnen Sie mit einer Bestandsaufnahme aller genutzten Skript-, Style- und Medienquellen, und testen Sie neue Regeln zunächst im report-only-Modus, bevor Sie sie scharf schalten.
Die konkrete Umsetzung hängt vom Server ab, ist aber CMS-unabhängig immer ein HTTP-Response-Header:
- Nginx:
add_header Content-Security-Policy "default-src 'self'; script-src 'self'" always;in der Server- oder Location-Direktive. - Apache:
Header set Content-Security-Policy "default-src 'self'; script-src 'self'"in der.htaccessoder Virtual-Host-Konfiguration. - Node/Express:
res.setHeader('Content-Security-Policy', "default-src 'self'")oder über Middleware wiehelmet. - CDN/Reverse-Proxy: viele Anbieter (Cloudflare, Fastly, CDN-Edge-Functions) bieten eine Header-Regel-Oberfläche, ohne dass der Ursprungsserver angefasst werden muss.
Testen Sie zunächst mit Content-Security-Policy-Report-Only statt Content-Security-Policy — der Browser meldet dann Verstöße in der Konsole (und optional an eine report-uri), blockiert aber noch nichts. Erst wenn keine unerwarteten Verstöße mehr auftauchen, schalten Sie auf den erzwingenden Header um. Für Inline-Skripte, die sich nicht vermeiden lassen, bieten sich Nonces (script-src 'nonce-<zufallswert>') oder Hashes (script-src 'sha256-<hash>') an, statt pauschal 'unsafe-inline' zu erlauben.
Fazit#
Ein fehlender CSP-Header ist eine der wirksamsten Schutzmaßnahmen gegen Code-Injection, die eine Website ungenutzt lässt. Die Einrichtung erfordert etwas Sorgfalt — vor allem eine saubere Bestandsaufnahme der genutzten Quellen und einen Testlauf im report-only-Modus —, ist aber unabhängig vom eingesetzten System auf Server- oder CDN-Ebene umsetzbar und schließt eine der grundlegendsten Sicherheitslücken im Web.
Häufige Fragen
Was ist eine Content-Security-Policy?
Die Content-Security-Policy (CSP) ist ein HTTP-Response-Header, mit dem eine Website dem Browser mitteilt, aus welchen Quellen Skripte, Styles, Bilder und andere Inhalte geladen werden dürfen. Alles außerhalb dieser Liste blockiert der Browser automatisch.
Wofür schützt CSP konkret?
CSP reduziert das Risiko von Cross-Site-Scripting (XSS) und ähnlichen Code-Injection-Angriffen erheblich, weil eingeschleuste Skripte in der Regel nicht aus einer erlaubten Quelle stammen und deshalb nicht ausgeführt werden.
Reicht ein CSP-Meta-Tag im HTML statt eines Headers?
Ein Meta-Tag funktioniert für die meisten Direktiven, unterstützt aber wichtige Direktiven wie frame-ancestors nicht und lässt sich leichter übersehen. Ein echter HTTP-Response-Header ist deshalb die zuverlässigere Lösung.
Kann eine zu strenge CSP die Website kaputt machen?
Ja, eine falsch konfigurierte CSP blockiert im schlimmsten Fall auch legitime Skripte oder Styles. Deshalb empfiehlt es sich, neue Regeln zunächst im report-only-Modus zu testen, bevor sie erzwungen werden.
EverAudit Redaktion
Fachredaktion für Web-Qualität, Barrierefreiheit und DSGVO. Wir prüfen jeden Ratgeber gegen die Kriterien unserer Audit-Engine.