Wie diese Prüfung funktioniert
Diese Prüfung greift nur, wenn deine Website bereits einen Content-Security-Policy-Header sendet; fehlt er, meldet das der Header-Scanner. Scanaris liest die komplette Richtlinie und sucht die zwei Wörter, die sie aushöhlen: 'unsafe-inline', das jedes direkt ins HTML geschriebene Skript oder Style ausführen lässt, und 'unsafe-eval', das erlaubt, mit eval und Verwandten Text in Code zu verwandeln. Taucht eines davon auf, öffnet es einen Fund mit niedrigem Schweregrad und der Liste der gefundenen Schwächen. Niedrig, weil eine unvollkommene CSP immer noch besser ist als keine, aber der Schutz gegen Skript-Injektion, der Daseinszweck der CSP, ist damit fast aufgehoben.
Warum es wichtig ist
Eine strikte CSP sorgt dafür, dass der Browser ein <script> selbst dann nicht ausführt, wenn ein Angreifer es in deine Seite bekommt (über einen unbereinigten Kommentar, einen gespiegelten Parameter oder eine kompromittierte Bibliothek). Mit 'unsafe-inline' in script-src läuft dieses injizierte Skript trotzdem: Der Header ist da, das Schloss wirkt geschlossen, aber die Tür steht offen. Wo das Wort steht, ist entscheidend: in script-src ist es ernst; in style-src ein viel kleineres Risiko, das viele Websites wegen ihrer Inline-Styles in Kauf nehmen.
Wie du es behebst
1. Nonces für Inline-Skripte
Ein Nonce ist ein bei jeder Anfrage anderer Zufallswert, den du in den Header und in jedes legitime <script>-Tag setzt. Der Browser führt nur Skripte mit diesem Wert aus; ein injiziertes Skript kennt ihn nicht.
Content-Security-Policy: script-src 'nonce-R4nd0m' 'strict-dynamic'; object-src 'none'; base-uri 'self'Next.js erledigt das in der Middleware, die den Nonce erzeugt und an Header und Komponenten weitergibt; Nuxt mit einem Server-Plugin, das ihn in jede Antwort injiziert (so macht es Scanaris); Express mit einer Middleware, die ihn in res.locals ablegt und in den Templates ausgibt.
2. Hashes für feste Skripte
Ändert sich ein Inline-Skript nie, berechne seinen SHA-256-Hash und trag ihn in die Richtlinie ein: 'sha256-…'. Das funktioniert für kleine Schnipsel, etwa den eines Tag-Managers, ohne Nonces aufzusetzen.
3. Code in Dateien verschieben
onclick="…"-Handler und Skriptblöcke im HTML sind der übliche Grund, 'unsafe-inline' zu brauchen. Verschieb sie in .js-Dateien von deiner Domain, und der Bedarf verschwindet.
4. unsafe-eval entfernen
Meist verlangt es eine alte Bibliothek oder der Entwicklungsmodus eines Frameworks, der in die Produktion gerutscht ist. Prüf in der Browser-Konsole, was es anfordert, und aktualisiere oder ersetze dieses Teil.
5. Im Report-Modus ausrollen
Veröffentliche die neue Richtlinie zuerst als Content-Security-Policy-Report-Only mit einer report-to- oder report-uri-Direktive auf einen eigenen Endpunkt. Sammle ein paar Tage, was sie blockieren würde, justiere nach, und wenn die Berichte sauber sind, stell auf den blockierenden Header um.
Prüf, ob es behoben ist
curl -sI https://deinedomain.com | grep -i "content-security-policy"In script-src darf weder 'unsafe-inline' noch 'unsafe-eval' stehen. Surf danach mit offener Konsole durch deine Website: Jede Blockierung erscheint dort mit der verursachenden Direktive. Die ganze Theorie steht in HTTP-Sicherheits-Header für Menschen erklärt.
Häufige Fragen
Ich nutze Tailwind oder Inline-Styles. Muss ich unsafe-inline aus style-src entfernen?
Wünschenswert, aber nicht dringend. Inline-Styles führen keinen Code aus. Priorisiere script-src; eine Richtlinie mit 'unsafe-inline' nur in style-src schützt vor dem, was zählt.
Google Tag Manager oder ein Support-Chat zwingen mich, die Richtlinie zu lockern.
Fast alle haben eine CSP-Dokumentation: Sie akzeptieren einen Nonce oder veröffentlichen die nötigen Hashes und Domains. Nimm ihre Origins in script-src und connect-src auf, statt alles zu öffnen.
Macht die CSP meine Website kaputt?
Nur, wenn du sie ohne Test auf Blockieren stellst. Dafür gibt es den Report-Modus: Er zeigt dir, was kaputtginge, ohne es kaputtzumachen.