Skip to content
NeuralSkills
Sicherheit

Eingabevalidierungs-Designer

Umfassende Eingabevalidierung entwerfen — Schema-Validierung, Sanitisierung, Typ-Coercion und Grenztests fuer jede Nutzereingabe.

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

Das Problem

Jede Sicherheitsluecke beginnt mit nicht vertrauenswuerdiger Eingabe. SQL Injection, XSS, Command Injection, Path Traversal — sie alle nutzen die Luecke zwischen dem, was man von Nutzern erwartet, und dem, was Angreifer tatsaechlich senden. Ueber Controller verstreute Validierung mit Ad-hoc-Regex-Checks ist fragil und inkonsistent. Man braucht eine zentralisierte, schemabasierte Validierungsstrategie, die boesartige Eingaben an der Grenze abweist, bevor sie die Geschaeftslogik erreichen.

Der Prompt

Du bist ein Eingabevalidierungs-Architekt. Entwirf eine umfassende Validierungsstrategie fuer die Nutzereingaben meiner Anwendung.

FRAMEWORK: [z.B. Express + Zod, FastAPI + Pydantic, Spring Boot, Next.js]
EINGABEQUELLEN: [z.B. Formularfelder, URL-Parameter, Query-Strings, JSON-Body, Datei-Uploads, Header]

ZU VALIDIERENDE ENDPUNKTE/FORMULARE:
[Endpunkte mit erwarteten Eingabefeldern und Typen auflisten]

Fuer jedes Eingabefeld Validierung entwerfen:

1. **Typvalidierung**: Erwarteter Typ, Strict-Mode (keine Coercion)
2. **Laengen-/Bereichsgrenzen**: Min/Max-Laenge, Zahlenbereiche
3. **Formatvalidierung**: E-Mail, URL, Telefon, Datum — mit Regex oder Bibliothek
4. **Allowlist/Denylist**: Enum-Werte, blockierte Muster
5. **Sanitisierung**: HTML-Encoding, Trim, Unicode-Normalisierung
6. **Geschaeftsregeln**: Feldueberzreifende Validierung, bedingte Anforderungen
7. **Fehlermeldungen**: Nutzerfreundliche Meldungen ohne interne Details

Zusaetzlich pruefen:
- Werden alle Query-Parameter validiert, nicht nur Body-Felder?
- Werden URL-Pfad-Parameter auf Typ und Format validiert?
- Werden Datei-Uploads auf Typ, Groesse und Inhalt validiert?
- Gibt es Schutz gegen Prototype Pollution beim JSON-Parsing?
- Sind Arrays und verschachtelte Objekte in der Groesse begrenzt?

Vollstaendiges Validierungsschema mit der Validierungsbibliothek meines Frameworks bereitstellen.

Beispielausgabe

## Validierungsschema: POST /api/users

const createUserSchema = z.object({
  email: z.string().email().max(254).trim().toLowerCase(),
  password: z.string().min(12).max(128),
  name: z.string().min(1).max(100).trim().regex(/^[a-zA-Z\s'-]+$/),
  age: z.number().int().min(13).max(150).optional(),
  role: z.enum(['user', 'editor']),  // niemals 'admin' vom Client erlauben
});

### Sicherheitshinweise:
- name: Regex verhindert Script-Injection ueber Sonderzeichen
- role: Enum verhindert Rechteerweiterung ueber beliebige Werte
- password: Max-Laenge verhindert bcrypt-DoS (72-Byte-Limit)

Wann verwenden

Validierungsschemata zu Beginn jedes neuen API-Endpunkts oder Formulars entwerfen. Ueberpruefen beim Hinzufuegen neuer Eingabefelder, Aendern von Datenformaten oder nach Entdeckung von Validierungs-Bypass-Bugs. Unverzichtbar bei Sicherheitsaudits und vor Endpunkten, die Finanz-, personenbezogene oder Authentifizierungsdaten verarbeiten.

Profi-Tipps

  • An der Grenze validieren — Eingaben im Moment des Eintreffens validieren, vor jeder Geschaeftslogik. Controller-Level-Validierung, nicht Service-Level.
  • Allowlist statt Denylist — definieren, was erlaubt IST, statt zu versuchen zu blockieren, was nicht erlaubt ist. Denylists uebersehen immer Randfaelle.
  • Content-Type nicht vertrauen — ein Angreifer kann einen JSON-Body mit Content-Type: text/plain senden. Den tatsaechlichen Inhalt validieren, nicht den Header.
  • Alles begrenzen — maximale Laengen fuer Strings, maximale Anzahl fuer Arrays und maximale Tiefe fuer verschachtelte Objekte setzen, um DoS ueber Payload-Groesse zu verhindern.