Was ist eine Content Security Policy?

Content Security Policy, kurz CSP, ist ein Sicherheitsmechanismus des Browsers. Eine Webanwendung liefert über einen HTTP-Response-Header Regeln aus, die festlegen, welche Skripte, Stylesheets, Bilder, Frames und Netzwerkverbindungen zulässig sind. Eine wirksame CSP kann Cross-Site Scripting und das Laden unerwünschter Drittinhalte verhindern oder deren Auswirkungen deutlich begrenzen.

Wie funktioniert eine Content Security Policy?

Der Server sendet den Header Content-Security-Policy mit der HTML-Antwort. Der Browser wertet die Direktiven aus, bevor er eine Ressource lädt oder Code ausführt. Passt eine Anfrage nicht zur Policy, blockiert der Browser sie und kann einen Verstoß melden. Die Kontrolle liegt damit auf der Clientseite, wird aber durch eine Vorgabe des Servers gesteuert.

CSP folgt dem Defense-in-Depth-Prinzip. Die Anwendung muss Benutzereingaben weiterhin korrekt behandeln, Ausgaben kontextabhängig kodieren und sichere DOM-APIs verwenden. CSP reduziert den möglichen Schaden, falls an anderer Stelle dennoch schädlicher Inhalt in eine Seite gelangt.

Welche CSP-Direktiven sind wichtig?

Nicht jede Direktive fällt auf default-src zurück. Besonders frame-ancestors, base-uri und form-action sollten deshalb bewusst gesetzt werden, wenn die jeweilige Einschränkung benötigt wird.

Wie sieht eine CSP beispielhaft aus?

Content-Security-Policy:
  default-src 'none';
  script-src 'nonce-RANDOM_VALUE' 'strict-dynamic';
  style-src 'self';
  img-src 'self' https://images.example;
  connect-src 'self' https://api.example;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';
  form-action 'self';

Dieses vereinfachte Beispiel sperrt zunächst alle nicht ausdrücklich erlaubten Ressourcen. Skripte benötigen den für die jeweilige Antwort erzeugten Nonce. Bilder dürfen von der eigenen Origin und einem festgelegten Bildserver stammen, API-Verbindungen von der eigenen Origin und einem API-Host. Plugin-Inhalte und das Einbetten der Seite in Frames werden verhindert. Eine reale Policy muss an die Anwendung angepasst und mit allen wichtigen Funktionen getestet werden.

Was sind Nonces und Hashes?

Ein Nonce ist ein zufälliger, nicht vorhersagbarer Wert, den der Server für jede Antwort neu erzeugt. Er steht sowohl in der CSP als auch im nonce-Attribut der erlaubten Script-Tags. Injizierter Code kennt diesen Wert nicht und wird blockiert. Der Nonce darf nicht statisch sein, nicht zwischen Antworten wiederverwendet und nicht aus angreiferkontrollierten Daten übernommen werden.

Ein Hash erlaubt genau einen bekannten Inline-Codeblock, dessen kryptografischer Hash in der Policy hinterlegt ist. Das eignet sich für statische Skripte, erfordert bei jeder Änderung aber einen neuen Hash. Host-Allowlisten allein sind häufig schwächer: Wird ein erlaubter Drittanbieter kompromittiert oder stellt er JSONP beziehungsweise Uploads bereit, kann die vertrauenswürdige Domain selbst zum Umgehungsweg werden.

Wie wird CSP sicher eingeführt?

1. Ressourcen erfassen: Skripte, Styles, Frames, APIs und tatsächlich notwendige Drittanbieter dokumentieren.
2. Unsichere Muster reduzieren: Inline-Handler, eval() und unnötigen Drittcode vor der Verschärfung entfernen.
3. Report-Only verwenden: Mit Content-Security-Policy-Report-Only Verstöße sammeln, ohne Inhalte sofort zu blockieren.
4. Policy schärfen: Quellen minimieren und für Skripte möglichst Nonces oder Hashes einsetzen.
5. Enforcement aktivieren: Kritische Benutzerwege, Fehlerseiten und seltene Funktionen vor und nach Aktivierung testen.
6. Berichte betreiben: Verstöße deduplizieren, Datenschutz beachten und neue Umgehungen oder Fehlkonfigurationen untersuchen.

Welche Fehler schwächen die Policy?

• 'unsafe-inline' erlaubt grundsätzlich Inline-Code und nimmt einer Script-Policy viel Schutzwirkung.
• 'unsafe-eval' erlaubt dynamische Codeausführung über Funktionen wie eval().
• Wildcards und sehr breite Schemas wie https: vertrauen deutlich mehr Quellen als nötig.
• Statische oder vorhersehbare Nonces können von Angreifern wiederverwendet werden.
• Eine Policy nur als HTML-meta-Tag unterstützt nicht alle Direktiven und wirkt erst ab ihrer Position im Dokument.
• Report-Only meldet Verstöße, blockiert sie aber nicht und darf nicht mit aktiver Durchsetzung verwechselt werden.

Welche Angriffe verhindert CSP nicht?

CSP behebt keine fehlerhafte Zugriffskontrolle, SQL Injection oder serverseitige Schwachstelle. Sie verhindert auch keinen Missbrauch erlaubter Anwendungsfunktionen. Eine schwache Policy kann umgangen werden, und ältere Browser unterstützen nicht jede Direktive gleich. CSP ist daher ein wichtiger zusätzlicher Schutz für den Browser, aber weder ein Ersatz für sichere Entwicklung noch ein Beweis, dass eine Anwendung frei von XSS ist.