Sicherheit
CSP erlaubt unsafe-inline — Schutz weitgehend wirkungslos
Woran du es erkennst
Die Content-Security-Policy existiert, erlaubt aber in script-src (oder über default-src) 'unsafe-inline' — damit dürfen beliebige Inline-Skripte laufen, genau die Angriffsfläche, die CSP schließen soll.
Warum es zählt
Eine CSP mit unsafe-inline im Skript-Bereich ist Sicherheitstheater: Sie sieht im Audit gut aus, stoppt aber klassisches XSS nicht, weil eingeschleuster Inline-Code weiterhin ausgeführt wird. Der Header erzeugt also falsche Sicherheit, ohne den wichtigsten Schutz zu liefern.
So behebst du es
- Verschiebe Inline-Skripte und Event-Handler (onclick=...) in externe Dateien — das ist meist der größte Teil der Arbeit.
- Für unvermeidbare kleine Inline-Blöcke nutze pro Request generierte nonces (script-src 'nonce-...') oder Hashes statt pauschalem unsafe-inline.
- Prüfe, ob unsafe-inline nur noch für einen Legacy-Fall gebraucht wird und entferne ihn schrittweise — mit Report-Only-Header beobachten, was bricht.
- Ergänze zusätzlich strict-dynamic, wenn Skripte zur Laufzeit weitere Skripte nachladen müssen.