Positive Security Model: Allowlist statt Blocklist

Das Positive Security Model dreht die Logik klassischer Filter um. Statt bekannte Angriffsmuster zu erkennen und zu blockieren (Blocklist, Negative Security Model), wird genau definiert, wie eine gültige Anfrage aussehen muss; alles andere wird abgewiesen. Eine API beschreibt dazu pro Endpunkt vollständig, welche Felder existieren, welchen Typ sie haben, welches Format und welche Wertebereiche zulässig sind. Was nicht im Schema steht, ist nicht erlaubt.

Der Vorteil ist strukturell: Eine Blocklist muss jeden denkbaren Angriff vorab kennen und scheitert an neuen Varianten und Umgehungstechniken (Encoding, Aufteilung, Polyglots). Eine Allowlist ist gegenüber unbekannten Eingaben robust, weil sie nicht das Böse sucht, sondern das Gute durchlässt. In der API-Welt liefert die Spezifikation diese Allowlist bereits: OpenAPI beschreibt Pfade, Methoden, Parameter und Bodies, und die einzelnen Datenstrukturen folgen dem JSON Schema-Vokabular.

Schema-Enforcement bedeutet, dieses Vertragsdokument zur Laufzeit durchzusetzen, nicht nur als Dokumentation zu führen. Jede Anfrage wird gegen das Schema validiert, bevor sie den Backend-Code erreicht.

AspektPositive Model (Allowlist / Schema)Negative Model (Blocklist / Filter)
GrundprinzipNur explizit Erlaubtes durchlassenBekannte Angriffsmuster blockieren
Schutz vor unbekannten AngriffenHoch, da nichtkonforme Eingaben abgewiesen werdenNiedrig, neue Varianten umgehen Filter
PflegeaufwandSchema muss aktuell und vollständig seinSignaturen müssen laufend ergänzt werden
Typische UmsetzungOpenAPI / JSON Schema am Gateway und im ServiceWAF-Signaturen, RegEx-Blocklisten
Schutz gegen Mass AssignmentJa, über additionalProperties false und readOnlyNein
Schutz gegen BOLA / LogikfehlerNein, erfordert AutorisierungslogikNein

Positive vs. Negative Security Model bei der Eingabevalidierung

Was validiert wird: Typ, Format, Länge, Pattern, Enum

JSON Schema stellt ein präzises Vokabular bereit, um Eingaben einzuschränken. Eine wirksame Validierung kombiniert mehrere Ebenen:

  • Typ: type: string, integer, boolean, object, array. Eine als Zahl erwartete ID darf kein Objekt oder Array sein.
  • Format und Pattern: format: email, format: uuid, format: date-time sowie reguläre Ausdrücke über pattern. So lässt sich erzwingen, dass eine Bestellnummer wirklich einem festen Muster entspricht.
  • Länge und Größe: minLength, maxLength für Strings, minimum, maximum für Zahlen, minItems, maxItems für Arrays. Längen- und Größengrenzen begrenzen zugleich den Ressourcenverbrauch.
  • Enum und Konstanten: enum schränkt ein Feld auf eine feste Menge erlaubter Werte ein, etwa einen Status auf ["offen", "bezahlt", "storniert"].
  • Pflichtfelder und Striktheit: required erzwingt vorhandene Felder; entscheidend ist additionalProperties: false, das alle nicht deklarierten Felder ablehnt. Genau dieser Schalter macht aus einer Dokumentation eine Allowlist.

Konsequent durchgesetzte Typ-, Format- und Pattern-Prüfung entzieht Injection-Angriffen die Grundlage, weil Sonderzeichen, überlange Payloads oder strukturfremde Werte gar nicht erst durchgereicht werden. Validierung ersetzt dabei nicht die parametrisierte Verarbeitung im Backend, sondern ergänzt sie als vorgelagerte Schicht.

Mass Assignment verhindern (Bezug zu BOPLA, API3:2023)

Mass Assignment entsteht, wenn ein Framework eingehende JSON-Felder automatisch auf interne Objekteigenschaften abbildet (Object Binding) und der Client dadurch Felder setzen kann, die nicht für ihn bestimmt sind. Sendet ein Angreifer beim Anlegen eines Kontos zusätzlich {"role": "admin"} oder {"verified": true} und übernimmt das Backend diese Felder ungeprüft, eskaliert er seine Rechte oder manipuliert internen Zustand.

Dieses Muster gehört zu BOPLA (Broken Object Property Level Authorization, API3:2023 in den OWASP API Security Top 10). BOPLA umfasst zwei Seiten: Excessive Data Exposure (die API gibt mehr Eigenschaften zurück als nötig) und Mass Assignment (die API akzeptiert mehr Eigenschaften, als der Client setzen dürfte).

Schema-Enforcement adressiert die Eingabeseite direkt. Mit additionalProperties: false und einer expliziten Eigenschaftsliste werden unbekannte oder schreibgeschützte Felder abgewiesen. Felder, die nur gelesen werden dürfen, lassen sich in OpenAPI mit readOnly: true markieren, sodass sie in Anfrage-Bodies nicht akzeptiert werden. Wichtig ist, getrennte Schemata für Eingabe und Ausgabe zu pflegen, statt dasselbe Datenmodell für beide Richtungen zu verwenden.

Request- und Response-Validierung am Gateway

Schema-Enforcement lässt sich zentral am API-Gateway durchsetzen, bevor Anfragen das Backend erreichen. Das Gateway lädt die OpenAPI-Definition und validiert eingehende Requests gegen Pfad, Methode, Parameter, Header und Body. Ungültige Anfragen werden mit 400 Bad Request abgewiesen, ohne dass fehlerhafte Eingaben den Anwendungscode belasten.

Auch die Response-Validierung ist sinnvoll: Antworten werden gegen das definierte Ausgabeschema geprüft, sodass keine ungewollten oder zusätzlichen Felder nach außen gelangen. Das begrenzt Excessive Data Exposure, selbst wenn das Backend versehentlich zu viele Daten serialisiert. Response-Validierung wirkt damit als zweite Verteidigungslinie auf der BOPLA-Ausgabeseite.

Zentrale Durchsetzung hat Vorteile: ein einheitlicher Validierungspunkt, konsistente Fehlerantworten und Entlastung der Services. Sie ersetzt aber keine Validierung in den Diensten selbst, denn nicht jeder Datenfluss läuft zwangsläufig über das Gateway. Sicherheit folgt dem Prinzip der Tiefenstaffelung: Gateway-Enforcement und serverseitige Validierung ergänzen sich. Die Spezifikation, gegen die validiert wird, muss zudem vollständig und gepflegt sein, sonst entstehen Lücken durch undokumentierte Endpunkte (Bezug Improper Inventory).

Grenzen: Validierung ersetzt keine Berechtigungsprüfung

Die wichtigste Einschränkung: Schema-Enforcement prüft die Form einer Anfrage, nicht deren Berechtigung. Eine syntaktisch und semantisch perfekt gültige Anfrage kann trotzdem ein schwerer Sicherheitsverstoß sein.

Das klassische Beispiel ist BOLA (Broken Object Level Authorization, API1:2023). Wenn ein Nutzer GET /accounts/1043 aufruft, ist die ID 1043 ein vollkommen valides Integer im erlaubten Wertebereich. Das Schema akzeptiert die Anfrage zu Recht. Ob der anfragende Nutzer auf genau dieses Konto zugreifen darf, ist eine reine Autorisierungsfrage, die ausschließlich die Anwendungslogik mit Bezug auf den authentifizierten Kontext beantworten kann. Validierung sieht hier nichts Verdächtiges.

Dasselbe gilt für BFLA (Berechtigung auf Funktionsebene), fehlerhafte Geschäftslogik und Missbrauch legitimer Abläufe (Business Flows). Diese Schwachstellen sind kontextabhängig und entziehen sich einer rein strukturellen Prüfung. Eingabevalidierung ist daher eine notwendige, aber nicht hinreichende Schutzschicht: Sie eliminiert Injection und Mass Assignment, doch Autorisierung, Authentifizierung und Logikprüfung müssen unabhängig davon korrekt implementiert sein.

Quellen

Weiterlesen
OWASP API Top 10BOPLA: Broken Object Property Level Authorization AngriffsklasseInjection in APIs OWASP API Top 10BOLA: Broken Object Level Authorization