Content-Security-Policy-Builder

Ein HTTP-Header, der steuert, welche Ressourcen ein Browser laden darf, und damit XSS- und Dateninjektionsangriffe verhindert.

Der erzwungene Modus blockiert Verstöße. Der Nur-Bericht-Modus erlaubt sie, meldet sie aber – nützlich zum Testen vor der Durchsetzung.

unsafe-inline erlaubt ausnutzbare Inline-Skripte. unsafe-eval ermöglicht die dynamische Codeausführung. Beides schwächt den CSP-Schutz erheblich.

Ja, der Content Security Policy Builder ist zu 100 % kostenlos – ohne Registrierung, ohne versteckte Gebühren und ohne Nutzungsbeschränkungen. Die gesamte Verarbeitung erfolgt lokal in deinem Browser und gewährleistet vollständige Privatsphäre.

Ja, der Content Security Policy Builder ist vollständig responsiv und funktioniert auf Smartphones und Tablets. Du kannst ihn auf jedem Gerät mit einem modernen Webbrowser nutzen – ohne App-Download.

Es ist kein Konto und keine Registrierung erforderlich. Öffne einfach den Content Security Policy Builder in deinem Browser und beginne sofort mit der Nutzung. Es gibt keine Anmeldeschranken oder Nutzungsbeschränkungen.

Gib einfach deine Daten in das vorgesehene Feld ein, passe die Einstellungen nach Belieben an, und das Tool verarbeitet sie sofort. Anschließend kannst du das Ergebnis in die Zwischenablage kopieren oder herunterladen.

Der Content Security Policy Builder funktioniert in allen modernen Browsern, darunter Chrome, Firefox, Safari, Edge und Opera. Für das beste Erlebnis verwende die neueste Version deines bevorzugten Browsers.

default-src ist die Fallback-Direktive: Sie legt die erlaubten Quellen für jeden Ressourcentyp fest, den du nicht explizit konfiguriert hast — sperrst du sie auf 'none' oder 'self', entsteht eine Deny-by-Default-Basis. script-src ist eine spezifische Überschreibung, die nur festlegt, woher JavaScript geladen werden darf, und hat für Skripte Vorrang vor default-src. Da Skripte der Hauptangriffsvektor für Cross-Site-Scripting sind, willst du fast immer eine strikte script-src, selbst wenn default-src bereits restriktiv ist — zum Beispiel default-src 'self' kombiniert mit einer separaten script-src 'self', die zusätzlich eine Nonce ergänzt. Andere ressourcenspezifische Direktiven wie style-src, img-src und connect-src funktionieren nach demselben Prinzip: Sie grenzen jeweils einen Ressourcentyp ein, während default-src den Rest abdeckt. Mit diesem Builder setzt du default-src einmal und überschreibst einzelne Direktiven nur dort, wo es nötig ist.

In Nginx fügst du die Policy innerhalb eines server- oder location-Blocks mit add_header Content-Security-Policy "deine Policy hier" always hinzu; das always-Flag stellt sicher, dass der Header auch bei Fehlerantworten wie 404s gesendet wird. In Apache verwendest du Header set Content-Security-Policy "deine Policy hier" innerhalb des passenden VirtualHost oder in der .htaccess, wobei mod_headers aktiviert sein muss. In beiden Fällen ist der Wert der vollständige Direktiven-String, und du lädst den Server neu, damit die Änderung wirksam wird. Die Syntax von Hand exakt hinzubekommen ist fehleranfällig, deshalb generiert dieser Builder fertige Copy-paste-Snippets für Nginx, Apache, Express.js und Next.js aus der Policy, die du konfigurierst. Stelle deine Direktiven visuell zusammen, wähle deinen Server aus und füge den generierten Block direkt in deine Konfiguration ein.

Eine CSP lässt sich auf zwei Wegen ausliefern: als Content-Security-Policy-HTTP-Response-Header oder als HTML-<meta http-equiv="Content-Security-Policy">-Tag im Seiten-Head. Die Meta-Tag-Methode ist praktisch, wenn du die Serverkonfiguration nicht bearbeiten kannst, aber die Spezifikation ignoriert bestimmte Direktiven in diesem Kontext bewusst. frame-ancestors, report-uri, report-to und sandbox funktionieren nur, wenn sie als echter HTTP-Header gesendet werden, weil sie bereits vor dem Rendern der Seite bekannt sein müssen oder sich auf Reporting auf Response-Ebene beziehen. Ist dir Schutz vor Clickjacking wichtig, muss frame-ancestors aus dem Header kommen, nicht aus dem Meta-Tag. Dieser Builder lässt dich zwischen Header- und Meta-Ausgabeformat wechseln und warnt dich, welche Direktiven im Meta-Modus wegfallen, damit du keine Policy ausrollst, die stillschweigend ihren Anti-Clickjacking-Schutz verliert.

Bei jeder Änderung wird ein Strictness Score von bis zu 100 Punkten neu berechnet, gestaffelt in Weak, Fair, Good oder Excellent. Der Score belohnt echte Schutzentscheidungen und nicht nur das bloße Vorhandensein einer Policy. Die meisten Punkte gibt es für eine restriktive default-src ('none' schlägt 'self'), eine script-src ohne unsafe-inline oder unsafe-eval, object-src 'none' und eine definierte frame-ancestors. Zusätzliche Direktiven wie base-uri, form-action, eine saubere style-src und weitere einschränkende Regeln schieben den Wert weiter nach oben, während Wildcard-Quellen und die unsicheren Schlüsselwörter ihn drücken. Der Report-Only-Modus senkt den Score leicht, da ein Report-Only-Header bis zur Durchsetzung keinen echten Blockierschutz bietet. Der Analysis-Tab listet genau auf, was deinen Score bestimmt, damit du siehst, welche Schwachstellen dich von Good zu Excellent bringen.

Eine Nonce ist ein zufälliges Token, das dein Server bei jedem Seitenaufruf neu generiert und sowohl in die CSP als auch in jedes vertrauenswürdige <script>-Tag einträgt; der Browser führt nur Skripte mit der passenden Nonce aus. Ein Hash funktioniert ähnlich, identifiziert aber ein bestimmtes Inline-Skript anhand seines sha256-Fingerabdrucks, ganz ohne Token pro Anfrage. Beide erlauben es dir, notwendige Inline-Skripte beizubehalten und gleichzeitig 'unsafe-inline' zu entfernen, das andernfalls jedes eingeschleuste Inline-Skript ausführen und deinen XSS-Schutz aushebeln würde. Kombinierst du eine Nonce zusätzlich mit 'strict-dynamic', können vertrauenswürdige Skripte auch ihre eigenen Abhängigkeiten laden, ohne dass du jede einzelne Domain auf die Whitelist setzen musst. Dieser Builder enthält Platzhalter-Quellwerte für Nonce und sha256 und empfiehlt, von unsafe-inline auf einen Nonce- oder Hash-basierten Ansatz umzusteigen. Konfiguriere script-src hier mit einem Nonce-Platzhalter und verdrahte anschließend das echte Token auf deinem Server.