Feldrechte in APIs: Mass Assignment und zu breite Antworten vermeiden

Zwei Richtungen derselben Grenze

Mass Assignment entsteht, wenn bequemes automatisches Binding mehr Eingabefelder auf interne Eigenschaften überträgt, als der Aufrufer verändern darf. Der Fehler kann erst bei einer späteren Modellerweiterung sichtbar werden: Ein neues internes Feld landet plötzlich auch im öffentlichen Änderungsweg.

Die umgekehrte Richtung ist eine zu breite Datenausgabe. Die Anwendung liefert beispielsweise einen internen Prüfvermerk, obwohl das Frontend nur den öffentlichen Status anzeigt. Das Ausblenden im Browser schützt den bereits übertragenen Inhalt nicht. OWASP fasst beide Richtungen in API3:2023 als Broken Object Property Level Authorization zusammen. OWASP API3:2023.

Zuerst muss der Zugriff auf das Objekt selbst erlaubt sein; dazu führt BOLA und IDOR. Danach legen Feldrechte fest, welchen Ausschnitt der Aufrufer bearbeiten beziehungsweise sehen darf. Ein gültiges JSON-Schema und ein vorhandener Schlüssel role entscheiden diese Berechtigung noch nicht.

Trennen Sie Eingabe, internen Zustand und Ausgabe

Ein Datenübertragungsmodell, häufig DTO genannt, beschreibt den gezielt freigegebenen Ausschnitt für eine Operation. Es muss nicht dieselben Eigenschaften besitzen wie das Datenbankmodell. Ebenso können Lesen und Schreiben verschiedene Modelle benötigen.

Diese Tabelle gilt für die fiktive Anwendung, nicht für jedes Produkt. Sie zeigt die Entwurfsfrage: Ein interner Wert kann notwendig sein und trotzdem in keinem öffentlichen Profilmodell vorkommen. OWASP empfiehlt ausdrücklich erlaubte Bindings und separate DTOs, statt externe Eingaben direkt auf Domänenobjekte abzubilden. OWASP Mass Assignment.

Explizite Feldauswahl bleibt bei Modellerweiterungen stabil

Das folgende lokale Python-Beispiel zeigt ausschließlich Feldauswahl. Voraussetzung: Die Anfrage ist bereits als Objekt geparst, die Werte wurden passend validiert, und der Aufrufer darf das betroffene Profil bearbeiten. Ohne diese vorgelagerten Entscheidungen wäre die Funktion kein sicherer Endpunkt.

EDITABLE_FIELDS = {"display_name", "time_zone"}

def select_profile_changes(payload):
    if set(payload) - EDITABLE_FIELDS:
        raise ValueError("Unzulässige Felder")
    return {
        name: payload[name]
        for name in EDITABLE_FIELDS
        if name in payload
    }

def public_profile(record):
    return {
        name: record[name]
        for name in ("id", "display_name")
    }

Ein später im internen Objekt hinzugefügtes review_note erscheint damit nicht automatisch in der Ausgabe. Ein zusätzliches role wird im Änderungsrequest abgelehnt, statt es in den Datensatz zu kopieren. Die beiden Funktionen wurden lokal mit synthetischen Daten geprüft. Rollenabhängige Modelle, verschachtelte Objekte, Datenbankzugriff und HTTP-Verhalten sind nicht enthalten.

Wenn verschiedene Rollen unterschiedliche Felder ändern dürfen, bestimmen Sie das zulässige Modell aus der serverseitigen Policy und der konkreten Aktion. Ein Clientparameter wie mode=admin darf diese Auswahl nicht selbst autorisieren. Auch ein umfangreiches „Adminmodell“ sollte keine unnötigen Geheimnisse ausgeben.

Ein Schema hilft nur, wenn es passend durchgesetzt wird

Ein Requestschema kann unerwartete Eigenschaften ablehnen. Bei einem einfachen JSON-Schema-Objekt schließt additionalProperties: false die nicht über properties oder patternProperties abgedeckten Eigenschaften aus. Die Einschränkung muss an der jeweiligen Objektebene stehen und mit den verwendeten Schema-Kompositionen korrekt zusammenwirken. JSON Schema Core 2020-12, Abschnitt 10.3.2.

Der Text in einer OpenAPI-Datei bewirkt für sich allein noch keine Laufzeitprüfung. Und selbst ein korrekt erzwungenes Schema kann die falschen Felder erlauben: Wenn role ausdrücklich im gewöhnlichen Profilmodell steht, hilft das Verbot zusätzlicher Felder nicht dagegen. Schema, Feldpolicy und tatsächliches Mapping müssen dasselbe beabsichtigte Verhalten beschreiben.

Annotationen wie readOnly oder writeOnly sind ebenfalls kein selbsttätiger Autorisierungsmechanismus. Ihr eingesetztes Werkzeug muss die jeweilige Bedeutung tatsächlich umsetzen; die Berechtigung dieses Aufrufers bleibt eine Anwendungsentscheidung. Der Validierungsleitfaden erklärt Struktur-, Werte- und Laufzeitprüfung.

Teiländerungen und verschachtelte Daten brauchen eigene Regeln

Bei Teilupdates sind „Feld fehlt“ und „Feld ist null“ oft verschieden: Das erste kann „unverändert lassen“, das zweite „Wert löschen“ bedeuten. Dokumentieren und prüfen Sie diese Bedeutung. Ein stiller Standardwert darf nicht aus einer ausgelassenen Eigenschaft eine unbeabsichtigte Änderung machen.

Verschachtelte Objekte sind keine Ausnahme. Wenn eine Kontaktadresse bearbeitbar ist, folgt daraus kein Recht, eine darin versteckte Organisationszuordnung zu ändern. Erlaubte Felder müssen deshalb rekursiv zu Ihrem konkreten Eingabevertrag passen. Bei Listen von Änderungen benötigt jedes betroffene Objekt zusätzlich eine Objektberechtigung.

Schreiben Sie interne Zustandsübergänge nicht als beliebig editierbare Felder aus. Eine Aktion „Bericht freigeben“ kann Rolle, Zustand und weitere Bedingungen prüfen; das freie Setzen von approved: true bildet diese Entscheidung häufig nicht ausreichend ab. Geschäftslogik absichern vertieft solche Abläufe.

Prüfen Sie gespeicherte Felder und tatsächlich versendete Daten

Verwenden Sie eine isolierte Umgebung mit synthetischen Profilen. Ein erlaubtes Feld muss sich ändern lassen; ein unzulässiges Feld darf den internen Wert nicht verändern. Kontrollieren Sie den gespeicherten Datensatz und abgeleitete Ereignisse, nicht nur den Responsebody. Manche internen Felder sind in einer Antwort absichtlich unsichtbar.

Für die Ausgabe vergleichen Sie die übertragenen Felder verschiedener Rollen und Wege. Eine Liste, ein Detailabruf, ein Export und eine GraphQL-Auswahl können unterschiedliche Serialisierer verwenden. Fügen Sie im Testmodell ein neues internes Feld hinzu und prüfen Sie, dass es ohne ausdrückliche Vertragsänderung weder ausgegeben noch übernommen wird. So prüfen Sie die beabsichtigte Grenze gegenüber späteren Modellerweiterungen.

Strengere Feldverträge ohne unkontrollierten Rückfall einführen

Ermitteln Sie vor einer Umstellung, welche zusätzlichen Felder legitime Clients heute senden. Entscheiden Sie ausdrücklich, ob solche Felder künftig abgelehnt oder zur Kompatibilität ignoriert werden. Beides kann fachlich sinnvoll sein; in keinem Fall dürfen nicht erlaubte Werte übernommen werden. Ein Fehlerhinweis sollte den Client zur Korrektur führen und keine internen Feldnamen oder Datenbestände auflisten.

Wenn die strengere Version einen benötigten Client blockiert, ergänzen Sie gezielt den erlaubten Vertrag oder kehren zu einer vorher geprüften engen Projektion zurück. Eine allgemeine Objektkopie als Rücknahme würde die Grenze wieder öffnen. Der öffentliche API Security Check überprüft diese Eingabe- und Ausgaberechte nicht.

Für den nächsten Schritt verbinden Rollen und Berechtigungen und API-Sicherheit selbst prüfen die Feldauswahl mit dem gesamten Aufruf. Bei öffentlichen Header- oder Methodensignalen führt HTTP-Befunde lesen zum passenden begrenzten Nachweis.

Passende nächste Schritte