API-Eingaben validieren: Von gültigem JSON zur erlaubten Verarbeitung

Prüfen Sie unterschiedliche Fehler an der passenden Stelle

OWASP trennt syntaktische von semantischer Validierung und weist ausdrücklich darauf hin, dass Eingabevalidierung nicht die hauptsächliche Abwehr gegen SQL Injection oder Cross-Site Scripting ersetzt. Daten von Partnerdiensten und internen Integrationen können ebenfalls ungeeignet oder manipuliert sein. OWASP Input Validation.

Setzen Sie Grenzen vor und während des Parsens

Ein Schema wird meist erst nach dem Einlesen des JSON-Objekts ausgewertet. Sein maxItems schützt deshalb nicht automatisch vor dem Aufwand, einen riesigen Body zunächst zu empfangen, zu entpacken und zu parsen. Begrenzen Sie je nach Architektur bereits Bodygröße, entpackte Größe, Zeit und geeignete Parserressourcen. Prüfen Sie, welche Schicht welche Grenze wirklich durchsetzt und wie komprimierte Inhalte behandelt werden.

Akzeptieren Sie nur benötigte Medientypen. Eine JSON-API muss nicht automatisch XML, native Objektserialisierung oder jede von einer Bibliothek unterstützte Darstellungsform annehmen. Deserialisierung, die aus fremden Daten beliebige Anwendungsklassen oder ausführbare Konstrukte erzeugt, benötigt besonders enge Kontrolle. Gewöhnliche Datenobjekte aus JSON vermeiden manche dieser Mechanismen, beseitigen aber keine Größen-, Werte- oder Berechtigungsprobleme. OWASP Deserialization.

Doppelte Eigenschaftsnamen verdienen eine bewusste Parserregel: Manche JSON-Parser behalten den letzten Wert, andere lehnen sie ab. Wenn vorgeschaltete Prüfung und Anwendung unterschiedlich entscheiden, können sie verschiedene Daten beurteilen. RFC 8259 empfiehlt eindeutige Objektnamen. Eine Ablehnung doppelter Namen ist eine geeignete eigene Vertragsentscheidung; ein nachträgliches Schema sieht verlorene Duplikate möglicherweise gar nicht mehr. RFC 8259, Abschnitt 4.

Ein kleines Schema für eine klar begrenzte Aufgabe

Das Beispiel beschreibt eine fiktive interne Terminbuchung. Titel, Platzanzahl und zwei Datumswerte müssen angegeben sein. Die Grenzen von 120 Zeichen und 20 Plätzen sind bewusste Beispielentscheidungen, keine allgemeinen Sicherheitswerte. Die Umgebung verwendet JSON Schema Draft 2020-12.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "title": { "type": "string", "minLength": 1, "maxLength": 120 },
    "seats": { "type": "integer", "minimum": 1, "maximum": 20 },
    "start_date": { "type": "string", "format": "date" },
    "end_date": { "type": "string", "format": "date" }
  },
  "required": ["title", "seats", "start_date", "end_date"],
  "additionalProperties": false
}

properties allein macht ein Feld nicht verpflichtend; das regelt hier required. Zusätzliche Eigenschaften werden durch additionalProperties: false für dieses einfache Objekt ausgeschlossen. Das gilt nicht automatisch für jedes verschachtelte Objekt oder jede Schema-Komposition. Eine Einordnung der erlaubten Felder liefert Mass Assignment vermeiden.

Prüfen Sie die Optionen Ihres Validators

In Draft 2020-12 ist format im Standarddialekt zunächst eine Annotation. Je nach Validator und Konfiguration wird das Datum daher nicht automatisch als Datum geprüft. Die Spezifikation unterscheidet ausdrücklich Format-Annotation und Format-Assertion. Legen Sie Dialekt, Bibliotheksversion und verwendete Formatprüfungen fest; prüfen Sie sie an einem absichtlich ungültigen Wert. JSON Schema Validation, Abschnitt 7.

Das folgende Beispiel verwendet die Python-Bibliothek jsonschema mit ausdrücklich zugeschaltetem FormatChecker. schema ist das als Python-Objekt geladene JSON aus dem vorigen Block. Nach der Schemavalidierung folgt die zusätzliche fachliche Datumsregel.

from datetime import date
from jsonschema import Draft202012Validator, FormatChecker

validator = Draft202012Validator(schema, format_checker=FormatChecker())

def validate_booking(data):
    validator.validate(data)
    start = date.fromisoformat(data["start_date"])
    end = date.fromisoformat(data["end_date"])
    if end < start:
        raise ValueError("Enddatum liegt vor dem Startdatum")
    return data

Dieses Beispiel wurde lokal mit gültigen Daten, falschen Typen, zusätzlichen Feldern, Grenzwerten, einem ungültigen Datum und umgekehrter Datumsreihenfolge geprüft. Es führt keine Buchung aus. Verfügbarkeit, Benutzerrechte, gleichzeitige Buchungen, Parserlimits und HTTP-Fehlerbehandlung sind darin nicht implementiert. Sie bleiben eigene Aufgaben.

Auch Typangaben im Anwendungscode sind kein Beweis einer Laufzeitprüfung externer Daten. TypeScript-Typannotationen werden beispielsweise beim Übersetzen entfernt; das eingehende JSON muss trotzdem tatsächlich validiert werden. Nutzen Sie ein gepflegtes Werkzeug, das zum konkreten Format passt, statt für alles eine neue komplexe reguläre Expression zu schreiben. TypeScript: Erased Types.

Gültige Daten brauchen weiterhin sichere Verwendung

Ein korrekt formatiertes Datum kann außerhalb des erlaubten Buchungsfensters liegen. Eine existierende Kunden-ID kann zu einer anderen Organisation gehören. Ein formal zulässiger Betrag kann vom Server statt vom Client bestimmt werden müssen. Diese Regeln gehören in die zuständige Anwendungsschicht und müssen mit den aktuellen Daten geprüft werden.

Verwenden Sie für Datenbankwerte parametrisierte Abfragen beziehungsweise die entsprechend sichere API Ihres Datenbanktreibers. Bauen Sie keine Anweisung durch Zusammenfügen von Requesttext. Für dynamische Spalten- oder Sortierbezeichner, die sich nicht als normale Werte binden lassen, ist eine feste Zuordnung erlaubter Optionen nötig. Bei Ausgaben in HTML oder anderen Interpretationskontexten braucht es die passende Ausgabekodierung; das globale Entfernen einiger Sonderzeichen löst diese Aufgabe nicht.

Ebenso berechtigt format: uri nicht zum Abrufen einer URL. Dafür müssen Zielwahl und ausgehender Zugriff gesondert begrenzt werden; dazu führt SSRF verhindern. Schemareferenzen selbst sollten aus kontrollierten Quellen stammen. Lassen Sie eine fremde Schemadatei nicht unbegrenzt Netzressourcen oder rechenintensive Prüfungen bestimmen.

Änderungen am Datenvertrag kontrolliert einführen

Sammeln Sie vor einer Verschärfung repräsentative synthetische Beispiele der legitimen Clients. Prüfen Sie insbesondere leere Werte, null, ausgelassene Felder und numerische Zeichenketten. Automatische Umwandlung kann Kompatibilität bieten, muss aber ausdrücklich zum Vertrag gehören und vor der fachlichen Entscheidung eindeutig sein.

Dokumentieren Sie bei abgelehnten Eingaben das betroffene öffentliche Feld und einen stabilen Grund. Geben Sie keine kompletten Requestbodies, Tokens oder internen Fehlerspuren zurück. Die Fehlerreferenz hilft bei 400, 413, 415, 422 und maschinenlesbaren Details. Ein fehlerhafter Request darf keine teilweise unerwünschte Änderung hinterlassen.

Wenn ein engeres Schema bestehende Clients blockiert, korrigieren Sie gezielt den Vertrag oder verwenden einen zuvor geprüften kompatiblen Validator. Eine Rücknahme sollte Größen- und Berechtigungsgrenzen erhalten. Der öffentliche API Security Check überprüft keine Requestschemas, Deserialisierer oder fachlichen Buchungsregeln. Für den eigenen Nachweis führt API-Sicherheit selbst prüfen weiter; öffentliche Inhaltstyp- und Methodenbeobachtungen erklärt HTTP-Befunde lesen.

Passende nächste Schritte