CSP (Content-Security-Policy)
CSP ist ein HTTP-Header, der erlaubte Ressourcen-Quellen whitelistet. Verhindert XSS durch Blockierung von Inline-Scripts und fremden Domains. Beispiel: Content-Security-Policy: script-src 'self'.
detaillierte erklärung
Content-Security-Policy (CSP) ist ein HTTP-Response-Header, der Browser anweist, nur Ressourcen von vertrauenswürdigen Quellen zu laden. Direktiven: script-src (JavaScript-Quellen), style-src (CSS), img-src (Bilder), connect-src (AJAX/WebSocket), default-src (Fallback für alle). Werte: 'self' (gleiche Origin), 'none' (blockiert alle), 'unsafe-inline' (erlaubt Inline-Scripts, UNSICHER), 'unsafe-eval' (erlaubt eval(), UNSICHER), Nonce ('nonce-abc123' für spezifische Inline-Scripts), Hash (SHA256-Hash des Scripts). Beispiel: Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com; style-src 'self' 'unsafe-inline'. XSS-Mitigation: Selbst wenn Angreifer <script>alert(1)</script> injiziert, blockiert CSP Ausführung (keine 'unsafe-inline'). Wichtig: CSP ist Defense-in-Depth, KEIN Ersatz für Input-Validation/Output-Encoding. Deployment: Report-Only-Modus für Testing (Content-Security-Policy-Report-Only).
warum ist das wichtig?
CSP ist moderne XSS-Abwehr - du musst verstehen, warum unsafe-inline gefährlich ist und wie Nonces funktionieren. Essentiell für Web-Security-Headers (securityheaders.com-Check) und OWASP-Top-10-Mitigation.
häufige fehler
- ⚠CSP ersetzt Input-Validation - Nein, CSP ist zusätzliche Schutzschicht (Defense-in-Depth)
- ⚠unsafe-inline ist manchmal ok - NEIN, macht CSP nutzlos für XSS-Schutz (Inline-Scripts sind Haupt-XSS-Vektor)
- ⚠CSP ist komplex, also weglassen - Nein, Start mit default-src 'self', iterativ verschärfen