json-validator.de

Ratgeber · JSON Schema 2020-12

Parsing ist nicht Validation: was JSON.parse leistet (und was nicht)

JSON.parse wirft bei kaputter Syntax. Schema-Validation prüft danach: gibt es das Pflichtfeld user_id? Ist die E-Mail gültig? Ist das Array nicht leer?

Foto von Jan-Tristan Rudat

Von Jan-Tristan Rudat

Redakteur json-validator.de

Was JSON.parse tatsächlich macht

JSON.parse ist ein nativer Bestandteil jeder modernen JavaScript-Engine. Es nimmt einen String und versucht ihn als JSON zu interpretieren. Output: ein JavaScript-Wert (Objekt, Array, String, Number, Boolean, null). Bei Fehler: SyntaxError.

Was JSON.parse NICHT macht

JSON.parse prüft nur die Syntax des JSON-Textes. Es interessiert sich nicht für:

  • Welche Felder vorhanden sind - alle sind willkommen
  • Welche Typen die Werte haben - alles was JSON kennt ist ok
  • Welche Werte überhaupt Sinn ergeben - "age": -500 ist akzeptiert
  • Ob die Struktur einem vereinbarten Schema entspricht

Was Schema-Validation hinzufügt

Schema-Validation prüft das geparste Objekt gegen einen "Vertrag":

const validator = ajv.compile({
  type: 'object',
  required: ['user_id', 'email'],
  properties: {
    user_id: { type: 'string', pattern: '^usr_[a-z0-9]{8}$' },
    email:   { type: 'string', format: 'email' }
  },
  additionalProperties: false
});

const parsed = JSON.parse(input);  // Syntax-Check
if (!validator(parsed)) {           // Schema-Check
  return errorResponse(validator.errors);
}
// Hier ist parsed garantiert eine gültige User-Struktur

Praktische Konsequenzen

Wenn dein Backend nur JSON.parse macht und dann auf req.body.user.email.toLowerCase() zugreift, ohne dazwischen Schema-Validation:

  • Tippfehler im Client (emial) führt zu undefined → toLowerCase crashes
  • Wrong type (number statt string) führt zu undefined function → crashes
  • Missing field führt zum gleichen crash
  • Stille Bug-Welle: einige Anfragen kommen durch, andere nicht

Mit Schema-Validation vor dem Handler: ein klarer 400-Response mit Liste der Verletzungen. Frontend-Dev kann sofort fixen.

Reihenfolge im Server-Code

// Express-Beispiel
app.use(express.json());          // 1. Body als String empfangen, JSON.parse
app.post('/users',
  validateSchema(userSchema),     // 2. Schema-Validation als Middleware
  usersController.create);         // 3. Erst dann Business-Logic

Die zweite Wahrheit: TypeScript ≠ Validation

TypeScript-Types existieren nur zur Compile-Zeit. Zur Laufzeit weiß deine App nicht, ob das Objekt das von JSON.parse kommt wirklich dem Type entspricht. as User ist ein leeres Versprechen.

// Type-Assertion lügt:
const user = JSON.parse(input) as User;
user.email.toLowerCase();  // crashes wenn email fehlt

// Validation gibt Sicherheit:
const validated = validateUser(JSON.parse(input));
validated.email.toLowerCase();  // safe - Schema garantiert die Struktur

Best-Practice

"Parse, don't validate" ist ein Buzzword aus der Functional-Programming-Welt. In der Praxis: Parse die Daten (JSON.parse), validiere die geparste Struktur (Schema), arbeite dann mit dem validierten Wert weiter. Drei separate Schritte, klare Verantwortlichkeiten.

Mehr zum Thema