Toolypet
Sicherheits-Tools/CSP-Builder

CSP-Builder

Content-Security-Policy-Header visuell erstellen

Voreinstellungen

Direktiven

Default fallback for other directives

Controls allowed JavaScript sources

Controls allowed CSS sources

Controls allowed image sources

Controls allowed font sources

Controls allowed fetch/XHR/WebSocket targets

Controls allowed iframe sources

Controls allowed plugin sources (Flash, etc.)

Restricts URLs for <base> element

Restricts form submission targets

Controls who can embed this page

Upgrade HTTP to HTTPS automatically

Optionen

Wenn aktiviert, werden Verstöße gemeldet aber nicht blockiert. Nützlich für Tests.

Generierter CSP-Header

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

Implementierungsbeispiele

add_header Content-Security-Policy "default-src 'self'";
Header set Content-Security-Policy "default-src 'self'"
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

CSP-Builder-Anleitung

Lernen Sie, wie Sie Content-Security-Policy-Header zum Schutz Ihrer Website erstellen

Was ist Content-Security-Policy?

Content-Security-Policy (CSP) ist ein HTTP-Response-Header, der hilft, Cross-Site-Scripting (XSS), Clickjacking und andere Code-Injection-Angriffe zu verhindern. Er ermöglicht Ihnen anzugeben, welche Inhaltsquellen auf Ihrer Website geladen werden dürfen, und gibt Ihnen feinkörnige Kontrolle über Skripte, Stile, Bilder und andere Ressourcen.

Verwendung

  1. Wählen Sie eine Voreinstellung (Streng, Moderat oder Entspannt) als Ausgangspunkt
  2. Aktivieren und konfigurieren Sie einzelne Direktiven basierend auf Ihren Bedürfnissen
  3. Überprüfen Sie Sicherheitswarnungen und passen Sie die Einstellungen entsprechend an
  4. Kopieren Sie den generierten Header und fügen Sie ihn Ihrer Webserver-Konfiguration hinzu

Beste Praktiken

Häufig gestellte Fragen

Was passiert, wenn ich CSP zu streng einstelle?

Wenn Ihr CSP zu streng ist, können legitime Ressourcen blockiert werden und die Funktionalität Ihrer Website beeinträchtigen. Deshalb wird empfohlen, mit dem Nur-Berichtsmodus zu beginnen. In diesem Modus werden Verstöße an Ihren Server gemeldet (wenn Sie eine report-uri konfigurieren), aber nicht tatsächlich blockiert, sodass Sie Probleme identifizieren können, bevor Sie die Richtlinie durchsetzen.

Was ist der Unterschied zwischen 'self' und 'none'?

'self' erlaubt Inhalte nur von der gleichen Quelle (gleiches Protokoll, Host und Port) wie Ihre Website. 'none' blockiert alle Inhalte dieses Typs. Zum Beispiel verhindert object-src 'none', dass alle Plugins (Flash, Java usw.) geladen werden, was eine Sicherheits-Best-Practice ist.

Warum gilt 'unsafe-inline' als gefährlich?

'unsafe-inline' erlaubt Inline-Skripte und -Stile, was einen Großteil des XSS-Schutzes von CSP zunichte macht. Angreifer, die HTML einschleusen können, können auch Inline-Skripte einschleusen. Verwenden Sie stattdessen Nonces (script-src 'nonce-random123') oder Hashes (script-src 'sha256-...'), um bestimmte Inline-Skripte zuzulassen und eingeschleuste zu blockieren.

Wie erlaube ich Google Analytics oder andere Drittanbieter-Skripte?

Fügen Sie die spezifische Domain zu Ihrer script-src-Direktive hinzu. Für Google Analytics benötigen Sie möglicherweise: script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com. Fügen Sie deren Domains auch zu connect-src für API-Aufrufe und zu img-src für Tracking-Pixel hinzu.

Kann CSP andere Sicherheitsheader ersetzen?

Nein, CSP ergänzt andere Sicherheitsheader. Sie sollten auch verwenden: X-Content-Type-Options: nosniff, X-Frame-Options (obwohl frame-ancestors in CSP dies ersetzen kann), X-XSS-Protection, Strict-Transport-Security (HSTS) und Referrer-Policy. Jeder Header behandelt unterschiedliche Sicherheitsbedenken.