Einleitung

Sicherheitslücken sind teuer – laut IBM kostet ein Datenbreach durchschnittlich $4.88 Millionen (2024). KI kann Schwachstellen finden, bevor Angreifer es tun. In diesem Artikel: 10 Prompts für Security-Audits, sichere Code-Patterns und Penetration Testing mit AI.

Wichtig: Diese Prompts sind für defensive Sicherheit gedacht – zum Schutz deiner eigenen Anwendungen. Teste nie fremde Systeme ohne ausdrückliche Genehmigung.

Deshalb ist es wichtig, diesen Abschnitt aufmerksam zu lesen.

Inhaltsverzeichnis

1. Prompt 1: Security Code Audit
2. Prompt 2: OWASP Top 10 Check
3. Prompt 3: Authentifizierung & Autorisierung
4. Prompt 4: Input-Validierung & Sanitization
5. Prompt 5: API Security
6. Prompt 6: Dependency Audit
7. Prompt 7: Environment & Configuration Security
8. Prompt 8: Kryptographie & Hashing
9. Prompt 9: Security Headers & CSP
10. Prompt 10: Penetration Test Plan
11. Security Checkliste
12. Tool-Empfehlungen
13. FAQ

Zusammenfassend bietet dieser Abschnitt praktische Handlungsempfehlungen.

Prompt 1: Security Code Audit

Insbesondere für den Einstieg sind die folgenden Informationen hilfreich.

Du bist ein Application Security Engineer. Führe ein Security Audit durch:

```
[Code hier einfügen]
```

Sprache/Framework: [z.B. "Node.js Express + TypeScript"]

Prüfe auf:
1. **Injection**: SQL Injection, NoSQL Injection, Command Injection, XSS
2. **Authentication**: Schwache Passwort-Policies, Session-Management
3. **Authorization**: IDOR (Insecure Direct Object References), Privilege Escalation
4. **Data Exposure**: Sensitive Daten in Logs, Responses, Error Messages
5. **Rate Limiting**: Fehlend bei Login, API-Endpunkten
6. **CSRF**: Cross-Site Request Forgery Protection
7. **File Upload**: Unrestricted Upload, Path Traversal
8. **Deserialization**: Unsafe Deserialization von User-Input

Für jede Schwachstelle:
- **Schweregrad**: Critical / High / Medium / Low
- **CVSS Score**: Geschätzt
- **CWE-Nummer**: z.B. CWE-89 (SQL Injection)
- **Angriffsszenario**: Wie kann die Lücke ausgenutzt werden?
- **Fix**: Konkreter Code-Fix
- **Prävention**: Wie verhindert man das in Zukunft?

Tatsächlich lässt sich dieser Code direkt in dein Projekt übernehmen.

Insbesondere für fortgeschrittene Projekte ist das relevant.

Prompt 2: OWASP Top 10 Check

Dennoch solltest du einige Besonderheiten beachten.

Prüfe meine Web-Anwendung gegen die OWASP Top 10 (2021):

App-Beschreibung: [z.B. "Next.js SaaS mit Stripe, PostgreSQL, NextAuth"]
Architektur: [z.B. "Server Components, API Routes, Prisma ORM"]

Für jeden OWASP-Punkt:
A01: Broken Access Control
A02: Cryptographic Failures
A03: Injection
A04: Insecure Design
A05: Security Misconfiguration
A06: Vulnerable and Outdated Components
A07: Identification and Authentication Failures
A08: Software and Data Integrity Failures
A09: Security Logging and Monitoring Failures
A10: Server-Side Request Forgery (SSRF)

Pro Punkt liefere:
1. Relevanz für meine App (Hoch/Mittel/Niedrig/N/A)
2. Potenzielle Angriffsvektoren
3. Aktuelle Schutzmaßnahmen (falls erkennbar)
4. Empfohlene Maßnahmen mit Code-Beispielen
5. Test-Strategie (wie verifiziere ich den Schutz?)

Im Grunde funktioniert dieser Ansatz mit allen gängigen AI-Tools.

Ebenso hilfreich ist ein strukturierter Ansatz bei der Umsetzung.

Prompt 3: Authentifizierung & Autorisierung

Darüber hinaus bietet dieser Abschnitt konkrete Beispiele und Tipps.

Überprüfe und verbessere mein Auth-System:

Aktuelles Setup:
[z.B. "NextAuth.js mit Credentials Provider, JWT Tokens, 
PostgreSQL User-Tabelle mit bcrypt Hashing"]

```
[Auth-relevanten Code hier einfügen]
```

Prüfe:
1. **Passwort-Hashing**: Algorithmus, Salt, Iterations
   (bcrypt/scrypt/argon2id, Kostenfaktor angemessen?)
2. **Session Management**: Token-Expiry, Refresh-Strategie, Revocation
3. **JWT Security**: Algorithm, Secret Length, keine sensiblen Daten im Payload
4. **Login-Schutz**: Rate Limiting, Account Lockout, Brute-Force Prevention
5. **Password Policy**: Mindestlänge, Komplexität, breached Password Check
6. **MFA**: Implementierung vorhanden? TOTP/WebAuthn?
7. **OAuth**: State Parameter, PKCE, Token-Validierung
8. **Authorization**: RBAC/ABAC, Middleware-Konsistenz
9. **Logout**: Session Invalidation, Token Blacklist

Liefere sichere Implementierung für alle gefundenen Probleme.

Deshalb empfiehlt es sich, den Prompt schrittweise zu verfeinern.

Folglich verbessert sich die gesamte Codequalität deutlich.

Prompt 4: Input-Validierung & Sanitization

Zusammenfassend lässt sich sagen, dass dies ein zentraler Aspekt ist.

Implementiere sichere Input-Validierung:

Framework: [z.B. "Express + Zod" oder "Next.js Server Actions"]

Eingaben die validiert werden müssen:
- [z.B. "User Registration: name, email, password"]
- [z.B. "Search Query: q Parameter"]
- [z.B. "File Upload: Profilbild (JPEG/PNG, max 5MB)"]
- [z.B. "Rich Text Editor: HTML-Content"]

Erstelle:
1. **Zod/Yup Schema** für jede Eingabe
2. **Sanitization**: HTML escapen, SQL-Sonderzeichen, Path Traversal
3. **XSS Prevention**: DOMPurify für Rich Text, Content-Security-Policy
4. **SQL Injection Prevention**: Parameterized Queries (nie String Concatenation)
5. **File Upload Validation**: Magic Bytes prüfen (nicht nur Extension), Virus Scan
6. **Rate Limiting** pro Endpunkt
7. **Size Limits**: Request Body, einzelne Felder, Arrays

Ziel: Zero Trust – vertraue keinem User-Input, validiere ALLES.

Weiterhin ist es sinnvoll, die Ergebnisse regelmäßig zu überprüfen.

Prompt 5: API Security

Somit kannst du direkt mit der Umsetzung beginnen.

Sichere meine API ab:

API-Typ: [REST / GraphQL / tRPC]
Auth: [z.B. "Bearer Token (JWT)"]

```
[API-Code hier einfügen]
```

Implementiere:
1. **Authentication**: Token-Validierung auf jedem Endpunkt
2. **Authorization**: User darf nur eigene Ressourcen sehen/bearbeiten (IDOR-Schutz)
3. **Rate Limiting**: 
   - Global: 100 req/min pro IP
   - Auth Endpunkte: 5 Versuche/min
   - API Keys: 1000 req/min pro Key
4. **Input Validation**: Schema-Validierung für Request Body/Params
5. **Output Filtering**: Keine internen IDs, Passwort-Hashes, Stack Traces
6. **CORS**: Nur erlaubte Origins
7. **API Versioning**: Breaking Changes sicher einführen
8. **Logging**: Alle Auth-Failures, Rate Limit Hits, 500er loggen
9. **API Key Management**: Rotation, Scoping, Revocation

GraphQL-Spezifisch (falls relevant):
- Query Depth Limiting
- Query Complexity Analysis
- Introspection in Production deaktivieren

Dabei zeigt dieses Beispiel den grundlegenden Ansatz.

Im Folgenden gehe ich auf die wichtigsten Details ein.

Prompt 6: Dependency Audit

Vor allem für den praktischen Einsatz sind diese Informationen wertvoll.

Führe ein Dependency Security Audit durch:

package.json:
```json
[package.json Inhalt hier einfügen]
```

Analysiere:
1. **Bekannte Vulnerabilities**: CVEs in aktuellen Versionen
2. **Veraltete Packages**: Major-Versionen hinter aktuell
3. **Unmaintained**: Packages ohne Updates seit > 1 Jahr
4. **Typosquatting-Risiko**: Ähnliche Namen zu populären Packages
5. **Übermäßige Dependencies**: Packages die zu viel mitbringen
6. **License-Risiken**: GPL-Packages in kommerzieller Software

Empfehlungen:
- Welche Packages sofort updaten (Security Fix)?
- Welche Packages ersetzen (bessere/sicherere Alternative)?
- Welche Packages entfernen (nicht genutzt / unnötig)?
- Lockfile Strategie (npm audit, Dependabot, Snyk)

Liefere npm/pnpm Befehle für alle Updates.

Insbesondere die Struktur des Prompts ist dabei entscheidend für gute Ergebnisse.

Tatsächlich zeigt die Praxis, dass dieser Ansatz sehr effektiv ist.

Prompt 7: Environment & Configuration Security

Ebenfalls relevant sind die praktischen Anwendungsbeispiele.

Prüfe meine Umgebungskonfiguration auf Sicherheit:

Umgebung: [z.B. "Next.js auf Vercel, PostgreSQL auf Supabase"]

Dateien zu prüfen:
- .env / .env.local
- next.config.js
- Dockerfile
- docker-compose.yml
- nginx.conf

Prüfe:
1. **Secrets in Code**: Keine API Keys, Passwörter in Git
2. **Environment Variables**: 
   - Sensible Vars nur server-seitig (kein NEXT_PUBLIC_ für Secrets)
   - Validierung beim Start (App crasht bei fehlenden Vars)
3. **Docker Security**: Non-root User, minimales Image, keine Secrets im Build
4. **HTTPS**: Erzwungen? HSTS Header? TLS 1.2+?
5. **Debug Mode**: In Production deaktiviert?
6. **Error Pages**: Keine Stack Traces in Production
7. **Default Credentials**: Datenbank, Admin-Panel, API Keys geändert?
8. **File Permissions**: .env Dateien nicht world-readable

Darüber hinaus lässt sich das Beispiel leicht erweitern.

Somit ergibt sich ein klarer Vorteil gegenüber manuellen Methoden.

Prompt 8: Kryptographie & Hashing

Dementsprechend solltest du die folgenden Aspekte kennen.

Überprüfe die Kryptographie in meiner App:

```
[Code mit Crypto-Operationen hier einfügen]
```

Analysiere:
1. **Passwort-Hashing**: 
   - ✅ argon2id oder bcrypt (Kostenfaktor >= 12)
   - ❌ MD5, SHA-1, SHA-256 (ohne Salt und Key Stretching)
   
2. **Encryption at Rest**:
   - AES-256-GCM für Datenverschlüsselung
   - Key Management (nicht im Code!)
   - IV/Nonce: Nie wiederverwenden

3. **Encryption in Transit**:
   - TLS 1.2+ erzwungen
   - Certificate Pinning (bei Mobile Apps)

4. **Token-Generierung**:
   - crypto.randomBytes() statt Math.random()
   - Ausreichende Entropy (min. 128 Bit)

5. **JWT**:
   - RS256 oder ES256 (nicht HS256 mit schwachem Secret)
   - Keine sensiblen Daten im Payload
   - exp und iat Claims gesetzt

Liefere sichere Implementierungen für alle gefundenen Probleme.

Hierbei hilft es, von konkreten Beispielen auszugehen.

Prompt 9: Security Headers & CSP

Allerdings gibt es einige wichtige Unterschiede zu beachten.

Konfiguriere Security Headers für meine Web-App:

Framework: [z.B. "Next.js" / "Express" / "Nginx"]
Features: [z.B. "Inline Scripts (Google Analytics), externe Bilder (CDN), 
iFrame Einbettung auf eigener Domain"]

Erstelle vollständige Konfiguration für:
1. **Content-Security-Policy (CSP)**:
   - default-src, script-src, style-src, img-src, connect-src
   - Nonce-basiert für Inline Scripts
   - Report-URI für CSP-Violations

2. **Strict-Transport-Security (HSTS)**:
   - max-age, includeSubDomains, preload

3. **X-Content-Type-Options**: nosniff
4. **X-Frame-Options**: DENY oder SAMEORIGIN
5. **Referrer-Policy**: strict-origin-when-cross-origin
6. **Permissions-Policy**: Kamera, Mikrophon, Location deaktivieren
7. **X-XSS-Protection**: 0 (veraltet, CSP ist besser)
8. **Cross-Origin Policies**: CORP, COEP, COOP

Teste mit: securityheaders.com (Ziel: A+ Rating)
Liefere die Konfiguration als next.config.js Headers oder nginx.conf.

Somit sparst du Zeit und erhältst qualitativ hochwertigeren Output.

Dennoch sollte man die Limitierungen im Blick behalten.

Prompt 10: Penetration Test Plan

Grundsätzlich gibt es dabei einige Punkte zu beachten.

Erstelle einen Penetration Test Plan für meine Anwendung:

App: [z.B. "SaaS Web-App mit User-Registrierung, Zahlungen, File Upload"]
Tech Stack: [z.B. "Next.js, PostgreSQL, Stripe, AWS S3"]
Scope: [z.B. "app.example.com, api.example.com"]

Test-Bereiche:
1. **Reconnaissance**: Subdomain Enumeration, Tech Stack Detection
2. **Authentication Testing**:
   - Brute Force Login
   - Password Reset Flow
   - Session Hijacking
   - OAuth Misconfigurations
3. **Authorization Testing**:
   - IDOR (andere User-Daten zugreifen)
   - Privilege Escalation (User → Admin)
   - API-Endpunkte ohne Auth
4. **Injection Testing**:
   - SQL Injection an allen Inputs
   - XSS (Reflected, Stored, DOM-based)
   - Command Injection
5. **Business Logic**:
   - Price Manipulation (Stripe)
   - Race Conditions (doppelte Transaktionen)
   - File Upload Exploits
6. **Infrastructure**:
   - SSL/TLS Configuration
   - Security Headers
   - Information Disclosure

Für jeden Test:
- Tool (Burp Suite, OWASP ZAP, Nuclei, etc.)
- Manuelle Schritte
- Erwartetes Ergebnis
- Erfolgs-/Misserfolg-Kriterien

Außerdem kannst du den Prompt für verschiedene Programmiersprachen anpassen.

Außerdem profitierst du von einem systematischen Vorgehen.

Security Checkliste (vor jedem Deploy)

Im Folgenden findest du alle wichtigen Details dazu.

Schnell-Check für mein Deployment:

□ npm audit / pnpm audit: Keine high/critical Vulnerabilities?
□ Secrets: Kein API Key / Passwort in Git?
□ HTTPS: Erzwungen mit HSTS Header?
□ Security Headers: CSP, X-Frame-Options, etc. gesetzt?
□ Auth: Rate Limiting auf Login/Register?
□ Input: Alle User-Inputs validiert und sanitized?
□ Errors: Keine Stack Traces in Production?
□ Logging: Auth-Failures und 500er werden geloggt?
□ CORS: Nur erlaubte Origins?
□ Database: Parameterized Queries, keine String Concatenation?
□ File Uploads: Type + Size validiert?
□ Admin-Zugänge: Default-Passwörter geändert?

Grundsätzlich kannst du diesen Prompt an deine Bedürfnisse anpassen.

Dementsprechend solltest du die einzelnen Schritte sorgfältig abarbeiten.

Tool-Empfehlungen

Deshalb lohnt es sich, dieses Thema genauer zu betrachten.

Zudem lassen sich die Ergebnisse auch auf andere Projekte übertragen.

FAQ

Kann AI Schwachstellen finden die Tools nicht finden?

Tatsächlich ist dieser Bereich besonders wichtig für Entwickler.

Ja – besonders bei Business Logic Bugs. SAST Tools prüfen Patterns (bekannte CVEs). AI versteht den Kontext und kann logische Fehler finden: „User A kann die Daten von User B sehen“ – das kann nur ein Modell erkennen, das die Business Logic versteht.

Ersetzt AI manuelle Penetration Tests?

Folglich profitierst du von einem besseren Verständnis dieser Konzepte.

Nein. AI ist ein Multiplikator, kein Ersatz. Automatisierte Tools + AI finden ~80% der Schwachstellen. Die restlichen 20% (Business Logic, komplexe Chains) brauchen menschliche Kreativität. Empfehlung: AI für das Screening, Pentester für den tiefen Dive.

Wie oft sollte ich Security Audits machen?

Ebenso wichtig ist es, die Best Practices zu kennen.

Automatisiert (CI/CD): Bei jedem PR. Manuell (Code Review): Vor jedem großen Release. Penetration Test: Mindestens jährlich, besser halbjährlich. Bei signifikanten Änderungen (neue Auth, Payment, File Upload): Sofort.

Kann ich AI für Hacking nutzen?

Im Grunde vereinfacht dieser Ansatz den gesamten Workflow erheblich.

AI-Modelle haben Guardrails gegen offensive Security. Für defensive Zwecke (eigene App testen) funktioniert es gut: „Finde Schwachstellen in MEINEM Code“ wird beantwortet. „Hacke diese Website“ wird abgelehnt. Nutze Bug Bounty Programme für externe Tests.

Zusätzlich gibt es einige bewährte Tipps für den Alltag.

Verwandte Artikel:

• AI für DevOps & CI/CD
• Zusätzlich Clean Code mit AI schreiben
• 50 ChatGPT Prompts für Entwickler

Darüber hinaus solltest du diesen Aspekt berücksichtigen.

Zuletzt aktualisiert: März 2026

Der Beitrag AI für Security & Penetration Testing erschien zuerst auf MetinCelik.de.