Skip to content
NeuralSkills
Code-Review

Sicherheits-Code-Review

Tiefgehende Sicherheitspruefung: Injection, XSS, CSRF, Auth-Bypass und Offenlegung sensibler Daten.

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

Das Problem

Sicherheitsluecken verstecken sich im Klartext. Ein Entwickler schreibt innerHTML = userInput ohne nachzudenken. Ein API-Endpunkt ueberspringt die Autorisierungspruefung, weil er “intern” ist. Ein JWT-Secret wird in einer Config-Datei committet. Standard-Code-Reviews fangen Stilprobleme, uebersehen aber systematisch diese Angriffsvektoren, weil Reviewern ein sicherheitsorientiertes Denkmodell fehlt. Eine uebersehene Schwachstelle kann die gesamte Nutzerbasis exponieren.

Der Prompt

Fuehre ein sicherheitsfokussiertes Code-Review fuer den folgenden Code durch. Handle als Penetrationstester, der Quellcode vor einem Sicherheitsaudit prueft.

SPRACHE/FRAMEWORK: [z.B. TypeScript/Next.js, Python/Django, Java/Spring]
DEPLOYMENT: [z.B. oeffentliche API, internes Dashboard, Mobile-Backend]

CODE:
[Code hier einfuegen]

Analysiere gegen die OWASP Top 10 (2021) plus diese zusaetzlichen Vektoren:

1. **Injection** (SQL, NoSQL, OS-Befehle, LDAP)
   - Wird Nutzereingabe jemals in Queries oder Befehle konkateniert?
   - Werden Parameterized Queries/Prepared Statements durchgaengig verwendet?

2. **Fehlerhafte Authentifizierung**
   - Werden Passwoerter mit bcrypt/argon2 gehasht (nicht MD5/SHA)?
   - Ist Session-Management sicher (httpOnly, secure, sameSite Cookies)?
   - Sind Rate Limits auf Login-/Reset-Endpunkten gesetzt?

3. **Offenlegung sensibler Daten**
   - Sind Secrets hardcodiert oder werden sie geloggt?
   - Sind personenbezogene Daten at-rest und in-transit verschluesselt?
   - Geben Fehlermeldungen Stack-Traces oder interne Pfade preis?

4. **XSS (Cross-Site Scripting)**
   - Wird Nutzereingabe vor dem Rendern in HTML sanitisiert?
   - Werden dangerouslySetInnerHTML / v-html / innerHTML mit untrusted Data verwendet?
   - Sind CSP-Header konfiguriert?

5. **CSRF (Cross-Site Request Forgery)**
   - Sind zustandsaendernde Endpunkte mit CSRF-Tokens geschuetzt?
   - Ist das SameSite-Cookie-Attribut gesetzt?

6. **Fehlerhafte Zugriffskontrolle**
   - Koennen Nutzer auf Ressourcen anderer Nutzer zugreifen (IDOR)?
   - Sind Admin-Endpunkte ueber das Verstecken der UI hinaus geschuetzt?
   - Wird Autorisierung auf Datenebene geprueft, nicht nur auf Route-Ebene?

7. **Sicherheitsfehlkonfiguration**
   - Sind Debug-Modi, Standard-Credentials oder verbose Fehler exponiert?
   - Sind CORS-Header zu permissiv (origin: *)?
   - Sind Sicherheitsheader gesetzt (X-Frame-Options, HSTS, CSP)?

8. **Supply Chain**
   - Sind Abhaengigkeiten auf exakte Versionen gepinnt?
   - Haben Pakete bekannte CVEs?

Fuer jede Schwachstelle liefere:
- **CWE-ID**: Common Weakness Enumeration Identifier
- **Schweregrad**: Kritisch / Hoch / Mittel / Niedrig
- **Angriffsvektor**: Wie ein Angreifer dies ausnutzen wuerde
- **Proof of Concept**: Beispiel fuer boesartige Eingabe
- **Fix**: Sicherer Code-Ersatz

Beispielausgabe

## Sicherheits-Review: 4 Schwachstellen gefunden

### KRITISCH — CWE-89: SQL Injection
Ort: src/api/users.ts:47
Code: `db.query("SELECT * FROM users WHERE email = '" + req.body.email + "'")`
Angriffsvektor: Angreifer sendet E-Mail: `' OR '1'='1' --`
PoC: curl -X POST /api/users -d '{"email": "' OR 1=1 --"}'
Fix:
  db.query("SELECT * FROM users WHERE email = $1", [req.body.email])

### HOCH — CWE-79: Stored XSS
Ort: src/components/Comment.tsx:12
Code: `<div dangerouslySetInnerHTML={{ __html: comment.body }} />`
Fix: DOMPurify verwenden: `<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(comment.body) }} />`

Wann verwenden

Bei jedem Pull Request ausfuehren, der Authentifizierung, Autorisierung, Nutzereingaben oder API-Endpunkte beruehrt. Unverzichtbar vor dem Deployment oeffentlich zugaenglicher Dienste, bei Zahlungsverarbeitung oder Verarbeitung personenbezogener Daten. Als Sicherheitsgate im Review-Workflow einsetzen — die Kosten, eine Schwachstelle vor der Produktion zu finden, sind um Groessenordnungen geringer als danach.

Profi-Tipps

  • Deployment-Kontext liefern — “oeffentliche API mit 50k Nutzern” loest andere Schweregrad-Bewertungen aus als “internes Admin-Tool hinter VPN.”
  • Mit Dependency-Audit verketten — nach dem Code-Review fragen: “Pruefe jetzt die package.json auf bekannte CVEs und riskante Abhaengigkeiten.”
  • Bedrohungsmodell anfordern — nachfragen: “Was sind basierend auf diesem Code die Top-3-Angriffsszenarien, die ein Angreifer versuchen wuerde?”
  • Fixes testen — fragen: “Generiere curl-Befehle, mit denen ich verifizieren kann, dass jede Schwachstelle behoben ist.”