Vorhaben besprechen

TOOLBOX · WERKZEUG

CSP PRÜFENUND BAUEN.

Content-Security-Policy einfügen und bewerten lassen oder mit Vorlagen neu erstellen. Mit fertiger Konfiguration für Ihren Server. Läuft nur in Ihrem Browser.

Header-Wert, eine Zeile „Content-Security-Policy: …“, eine Zeile aus nginx oder Apache oder ein <meta>-Tag. Die Analyse läuft vollständig in Ihrem Browser: Ihre Richtlinie verlässt das Gerät nicht und wird nirgends gespeichert.

Rein im Browser: Dieses Werkzeug sendet nichts an TOMORIS oder Dritte. Header Ihrer Website prüfen

SO FÜHREN SIE DIE CSP EIN

Erst beobachten.
Dann durchsetzen.

Eine CSP, die eigene Inhalte blockiert, fällt schnell wieder raus. Mit Report-Only sehen Sie vorher, was die Richtlinie sperren würde.

  1. 01

    Vorlage wählen

    Die Vorlage, die Ihrer Website am nächsten kommt, und die Direktiven an Ihre Quellen anpassen.

  2. 02

    Als Report-Only ausliefern

    Den Header Content-Security-Policy-Report-Only setzen. Der Browser meldet Verstöße in der Konsole und, falls eingetragen, an Ihre Melde-Adresse.

  3. 03

    Meldungen auswerten

    Fehlende eigene Quellen ergänzen, unerwartete Quellen prüfen. Inline-Skripte mit Nonce oder Hash freigeben.

  4. 04

    Durchsetzen

    Dieselbe Richtlinie als Content-Security-Policy ausliefern und mit dem Security-Header-Check kontrollieren.

GRUNDLAGEN

Geprüft nach
offenen Regeln.

Die Bewertung folgt veröffentlichten Regeln. Vorlagen mit Diensten Dritter nennen nur die Hosts aus der Dokumentation des Herstellers.

FRAGEN

Gut zu wissen.

Was ist eine Content-Security-Policy?

Eine Content-Security-Policy (CSP) ist eine Anweisung Ihres Servers an den Browser, aus welchen Quellen eine Seite Skripte, Styles, Bilder und andere Inhalte laden darf. Eingeschleuster Code aus anderen Quellen wird blockiert. Damit ist die CSP der wichtigste zusätzliche Schutz gegen Cross-Site-Scripting (XSS).

Wird meine Richtlinie an TOMORIS übertragen?

Nein. Analyse und Generator laufen vollständig in Ihrem Browser. Die Seite sendet Ihre Eingaben nirgendwohin und speichert sie nicht.

Nach welchen Regeln wird bewertet?

Nach der W3C-Spezifikation Content Security Policy Level 3 und den Prüfungen des Google CSP Evaluator: unter anderem 'unsafe-inline', 'unsafe-eval', Platzhalter wie * oder https: in script-src, die Wirkung von 'strict-dynamic', das Format von Nonce und Hash, fehlende object-src, base-uri, frame-ancestors und form-action sowie Schreibfehler. Die Grundregeln teilt die Analyse mit dem Security-Header-Check; darüber hinaus erkennt sie Feinheiten wie ungültige Nonces oder Platzhalter der Form https://*.

Warum zuerst als Report-Only testen?

Eine zu enge Richtlinie blockiert auch eigene Skripte, Schriften oder Analyse-Aufrufe. Im Modus Content-Security-Policy-Report-Only meldet der Browser Verstöße nur, blockiert aber nichts. Erst wenn keine unerwarteten Meldungen mehr kommen, setzen Sie dieselbe Richtlinie als Content-Security-Policy durch.

Header oder meta-Tag?

Der HTTP-Header ist der empfohlene Weg. Im meta-Tag wirken frame-ancestors, report-uri und sandbox nicht, und Report-Only wird dort gar nicht unterstützt. Das meta-Tag ist eine Notlösung, wenn Sie keine Header setzen können.

Was bewirkt 'strict-dynamic'?

Mit 'strict-dynamic' dürfen Skripte, die einen gültigen Nonce oder Hash tragen, weitere Skripte nachladen. Hosts, Schemata wie https:, 'self' und 'unsafe-inline' ignorieren Browser dann. Die Richtlinie hängt so nicht mehr an Listen erlaubter Server, die sich oft umgehen lassen.

TOOLBOX

Weitere
Werkzeuge.

IHR NÄCHSTER SCHRITT

Ergebnis da.
Und jetzt?

Wir ordnen Befunde ein, priorisieren nach Risiko und setzen auf Wunsch um: einmalig mit EXPERTS oder laufend im Betrieb mit GRID.

Ergebnis besprechen