API-Autorisierung versagt unbemerkt: Testen Sie jedes Objekt, jede Rolle und jede Aktion

Kurz gesagt: Die Authentifizierung weist nach, wer eine Anfrage gestellt hat; die Autorisierung entscheidet, was diese Identität tun darf. Die API-Sicherheit versagt, wenn Teams nur die erste Frage testen und davon ausgehen, dass die zweite überall korrekt beantwortet wird.

Ein gültiges Token ist kein Berechtigungsschein

Moderne APIs schützen schwache Kontrollen auf Objektebene häufig durch eine starke Authentifizierung. Eine Anfrage kann eine vollkommen gültige Sitzung oder ein gültiges Zugriffstoken enthalten und dennoch die Rechnung, das Projekt, den Export oder eine administrative Aktion eines anderen Kunden anfordern. Wenn der Handler lediglich prüft, ob der Aufrufer angemeldet ist, hat die API die falsche Sicherheitsfrage beantwortet.

Dieser Fehler wird leicht übersehen, weil normale Produkttests dem vorgesehenen Ablauf folgen. Der Eigentümer öffnet seinen eigenen Datensatz, ein Administrator verwendet einen Administrator-Endpunkt und jede Anfrage wird genau wie erwartet ausgeführt. Autorisierungsfehler treten erst auf, wenn Identität, Objekt, Mandant oder Aktion bewusst nicht zueinander passen.

Erstellen Sie eine vollständige Autorisierungsmatrix

• Testen Sie jede Objektoperation als Eigentümer, als gleichberechtigter Benutzer desselben Mandanten, als Benutzer eines anderen Mandanten und als nicht authentifizierter Aufrufer.
• Testen Sie Lese-, Erstellungs-, Aktualisierungs-, Lösch-, Export-, Einladungs- und Genehmigungsaktionen unabhängig voneinander; eine geschützte Methode beweist nicht, dass auch die anderen geschützt sind.
• Ändern Sie Kennungen in Pfaden, Abfrageparametern, JSON-Bodys, Headern und verschachtelten Objekten, anstatt nur das offensichtliche URL-Feld zu testen.
• Überprüfen Sie Rollenwechsel und veraltete Sitzungen, damit herabgestufte oder entfernte Benutzer ihre Berechtigungen nicht durch zwischengespeicherte Ansprüche behalten können.

An der Datengrenze standardmäßig verweigern

Das zuverlässigste Design bindet jede Abfrage sowohl an das angeforderte Objekt als auch an den autorisierten Geltungsbereich des Aufrufers. Wird ein Datensatz anhand seiner Kennung abgerufen und die Eigentümerschaft erst anschließend geprüft, entstehen Spielräume für vergessene Prüfungen, Seitenkanäle und eine uneinheitliche Fehlerbehandlung. Eine Abfrage innerhalb der Mandanten- oder Eigentumsgrenze macht die sichere Bedingung zu einem Bestandteil des Abrufs selbst.

Zentrale Richtlinienhelfer verringern Abweichungen, ersetzen jedoch keine Tests. Jeder Endpunkt benötigt weiterhin negative Prüfungen, die belegen, dass nicht berechtigte Identitäten weder Daten erhalten noch Zustandsänderungen auslösen. Eine 403-Antwort ist nur dann ein nützlicher Nachweis, wenn die Datenbank und nachgelagerte Seiteneffekte unverändert bleiben.

Nachweise sollten belegen, dass der verbotene Pfad geschlossen blieb

Ein aussagekräftiger Autorisierungstest erfasst den Aufrufer, die Rolle, den Mandanten, das Zielobjekt, die Anfrage, die Antwort und den Zustand nach der Anfrage. Dieser Nachweis unterscheidet eine echte Kontrolle von einer Einschränkung im Frontend oder einem Statuscode, der eine bereits ausgeführte Aktion verschleiert.

KENSAI behandelt die Validierung von Zugriffskontrollen als Matrix und nicht als einzelnen Scan des vorgesehenen Ablaufs. Ziel ist es, die Isolation zwischen Identitäten und Aktionen nachzuweisen und anschließend genügend Nachweise aufzubewahren, um jede Verletzung einer Sicherheitsgrenze reproduzieren und ihre Behebung überprüfen zu können.

Fazit

Autorisierung ist eine Beziehung zwischen einer Identität, einem Objekt und einer Aktion. Testen Sie alle drei Dimensionen mit Negativfällen und weisen Sie nach, dass verbotene Anfragen weder zur Offenlegung von Daten noch zu Seiteneffekten führen.