1. Kurzbeschreibung
Es ist keine Content-Security-Policy konfiguriert.
Das ist die anspruchsvollste „niedrige“ Schwachstelle im Bericht.
CSP schützt vor XSS-Folgen, nicht vor XSS selbst. Sie ist eine Schadensbegrenzungsschicht. In modernen SPAs mit vielen Drittquellen ist eine strenge CSP schwierig.
Der Bericht weist korrekt darauf hin, dass eine strenge CSP oft strukturelle Änderungen erfordert (S.11). Das ist der entscheidende Punkt.
Wenn die Anwendungen viele Inline-Skripte nutzen oder dynamisch generierten Code haben, wird eine saubere CSP nicht trivial.
2. Bewertung
- Risiko: Erhöhte Auswirkungen bei XSS.
- Angriffsvektor: Eingeschleuster JavaScript-Code.
- Auswirkung: Datenexfiltration / Session-Übernahme.
- Realistische Bedrohung: Abhängig von XSS-Findings.
3. Lösung
Phase 1 (geringer Aufwand):
- CSP mit Report-Only einführen
- Keine Wildcards
- Kein unsafe-inline
- Reports sammeln
Phase 2:
- Inline-Skripte entfernen
- Nonces oder Hashes nutzen
- Externe Ressourcen sauber whitelisten
Wenn React sauber konfiguriert ist, ist das deutlich einfacher als bei historisch gewachsenen Server-Templates.
4. Notizen
Inline-Skripte prüfen.
Hier ist Architekturqualität entscheidend. Eine moderne SPA lässt sich viel leichter härten als ein Template-Monolith mit Inline-JS.