Anmeldung, Funktion und Datensatz sind verschiedene Fragen
Authentifizierung liefert die geprüfte Identität beziehungsweise den nach Ihrem Zugangsmodell belegten Aufrufer. Autorisierung legt dessen erlaubte Handlungen fest. Fehlt die Grenze an einer Funktion, spricht OWASP von Broken Function Level Authorization oder BFLA: Ein gewöhnlicher Nutzer kann beispielsweise einen organisationsweiten Export starten, der nur ausgewählten Verantwortlichen zusteht.
Der Pfadname /admin/ schützt diese Funktion nicht. Ebenso wenig genügt es, den Exportknopf im Frontend auszublenden. Prüfen Sie die Befugnis am serverseitigen Aufrufweg, unabhängig davon, welcher Client ihn verwendet. OWASP API5:2023.
Eine erlaubte Exportfunktion bedeutet noch nicht, dass alle Datensätze exportiert werden dürfen. Das bestimmen zusätzlich Objektrechte, Mandantengrenzen und gegebenenfalls Feldrechte. Eine einzige globale Abfrage „Ist angemeldet?“ kann diese Entscheidungen nicht ersetzen.
Welches Regelmodell passt zur Aufgabe?
Sie müssen nicht für jedes Produkt eine eigene Policy-Sprache einführen. Entscheidend ist, dass das Modell die vorgesehenen Freigaben verständlich ausdrückt und durchgesetzt werden kann.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Modell | Geeignete Frage | Typische Grenze |
|---|---|---|
| Rollenbasiert, RBAC | Welche Aufgaben hat eine Person, etwa Leser oder Abrechnungsverantwortlicher? | Eine Rolle allein beschreibt selten, an welchen konkreten Objekten sie gilt |
| Attributbasiert, ABAC | Passen Merkmale des Aufrufers, Objekts und Kontexts, etwa Organisation und Freigabestatus? | Herkunft und Aktualität der Attribute müssen verlässlich sein |
| Beziehungsbasiert, ReBAC | Ist die Person Eigentümerin, Teammitglied oder ausdrücklich freigegebene Leserin? | Änderungen und Widerruf der Beziehungen müssen jeden Zugriff erreichen |
Die Begriffe schließen einander nicht aus. „Abrechnungsverantwortlicher im Mandanten des Belegs darf einen noch offenen Beleg freigeben“ verbindet Rolle, Organisation und Objektzustand. Eine verständliche kombinierte Regel ist oft besser als Dutzende Rollen, die jede Ausnahme im Namen verstecken. OWASP beschreibt diese Modelle und empfiehlt besonders für feingranulare Rechte die Berücksichtigung von Attributen und Beziehungen. OWASP Authorization.
Ein OAuth-Scope ist keine vollständige Geschäftsregel
Scopes begrenzen den mit einem Access Token gewährten Zugriffsbereich. Ihre Namen und Bedeutung werden durch den Autorisierungsserver beziehungsweise das gemeinsame API-Profil definiert. reports:write ist daher kein universeller Standard für sämtliche Schreibrechte. Der Client kann einen Scope anfordern; er darf nicht annehmen, dass er genau diesen Umfang auch erhalten hat. RFC 6749, Abschnitt 3.3.
Für eine Anwendung mit delegiertem Benutzerzugriff könnte die Regel lauten: Das Token gilt für diese API, erlaubt die Aktion, und der Benutzer besitzt im betroffenen Mandanten die erforderliche fachliche Befugnis. Danach folgen Objekt- und Zustandsprüfung. Die konkret eingesetzte Architektur bestimmt, welche dieser Informationen im Token stehen und welche die Anwendung aktuell nachschlägt.
Bei einem Dienstkonto gibt es möglicherweise keinen handelnden Benutzer. Definieren Sie dann ausdrücklich, welche Organisationen, Datensätze und Aktionen dem Dienst selbst zugeordnet sind. Erfinden Sie keinen Benutzerkontext aus einem beliebigen Tokenfeld. Die OAuth-/OIDC-Einordnung und JWT-Validierung erklären die vorgelagerte Vertrauensprüfung.
Schreiben Sie Aktionen und zusätzliche Bedingungen auf
Diese Matrix beschreibt ein fiktives Teamprodukt. Die Rollen gelten jeweils nur innerhalb einer Organisation; eine andere Anwendung kann andere Entscheidungen benötigen.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Aktion | Rolle oder Befugnis | Weitere Bedingung |
|---|---|---|
| Bericht lesen | Leser oder Bearbeiter | Eigenes oder freigegebenes Objekt im erlaubten Mandanten |
| Bericht bearbeiten | Bearbeiter | Schreibrecht am Objekt und bearbeitbarer Zustand |
| Bericht endgültig freigeben | Freigabeverantwortlicher | Zulässiger Übergang; bei gewünschtem Vier-Augen-Prinzip andere Person als der Bearbeiter |
| Gesamtexport starten | Explizite Exportbefugnis | Definierter Datenumfang, Feldrechte und Ressourcenbudget |
| Rollen vergeben | Rollenverwaltung | Nur die ausdrücklich zuweisbaren Rollen, kein automatisches Recht zur Selbsterhöhung |
Lesen und Ändern können sich dieselbe URL teilen und durch die HTTP-Methode unterschieden werden. Prüfen Sie die tatsächlich ausgeführte Aktion. Eine Methodenzulassung im Router ist nur ein Teil davon. Bei GraphQL liegt die fachliche Aktion innerhalb einer Operation; ein erlaubtes POST /graphql erteilt keine allgemeine Freigabe aller Mutations.
Für neue Funktionen sollte die Integration scheitern oder der Zugriff geschlossen bleiben, solange keine ausdrückliche Regel existiert. Eine zentrale Policy kann diese Zuordnung vereinheitlichen. Ihre Durchsetzung muss trotzdem an allen relevanten Aufrufwegen angebunden sein: Webcontroller, interne Dienste, Jobs und administrative Werkzeuge haben nicht automatisch dieselbe Vertrauensstufe.
Planen Sie Rechteänderungen und Ausfälle mit
Eine Rolle kann nach der Tokenausstellung entzogen werden. Wenn die API ausschließlich alte Tokenclaims auswertet, wirkt der Entzug möglicherweise erst später. Bestimmen Sie deshalb die erlaubte Verzögerung für jede sensible Aktion und wählen Sie dazu kurze Gültigkeit, aktuelle Nachschläge, Invalidierung oder ein anderes geeignetes Verfahren. Ein allgemeines „Logout“ beantwortet diese Frage nicht.
Dasselbe gilt für zwischengespeicherte Policyentscheidungen. Der Cache muss mindestens die entscheidungsrelevanten Identitäten, Objekte, Aktionen und den Rechtezustand unterscheiden. Bei Ausfall der Rechtequelle darf eine unbekannte Entscheidung nicht unbemerkt zu „erlaubt“ werden. Wo Verfügbarkeit und Sicherheit in Spannung stehen, braucht es einen bewusst begrenzten Betriebsmodus, etwa das Abschalten sensibler Änderungen.
Dokumentieren Sie privilegierte Ausnahmen wie Supportzugriff oder Notfallverwaltung separat: Anlass, Umfang, wirksame Begrenzung und interne Nachvollziehbarkeit. Die Existenz einer technischen Administratorrolle ist noch keine Begründung dafür, sie im normalen Anfragepfad zu verwenden.
Prüfen Sie die Regel an der ausgeführten Wirkung
Verwenden Sie eigene Testidentitäten mit verschiedenen Rechten in einer isolierten Umgebung. Prüfen Sie den erlaubten Fall und jeweils genau den fehlenden Baustein: richtiger Scope ohne fachliche Rolle, richtige Rolle im falschen Mandanten, erlaubter Benutzer mit entzogenem Recht und unbekannte Funktion ohne Policy.
Der Nachweis umfasst Antwort, geschützte Daten und ausgelöste Wirkung. Eine verweigerte Exportanfrage darf keinen herunterladbaren Export erzeugen; eine gesperrte Freigabe darf keinen neuen Status hinterlassen. Ein korrekter Fehlercode bei bereits erfolgter Nebenwirkung wäre weiterhin ein Fehler. Halten Sie die gewollten Ausnahmen als Positivfälle fest, damit spätere Härtung sie nicht versehentlich entfernt.
Bei der Einführung beginnen Sie mit einer geprüften Policyversion und klar begrenzten Funktionen. Falls eine neue Zuordnung legitime Arbeit blockiert, korrigieren Sie diese Zuordnung oder nehmen die betroffene Funktion kontrolliert außer Betrieb. Ein globaler Bypass der Autorisierung ist keine sichere Rücknahme. Für den vollständigen Prüfablauf führt API-Sicherheit selbst prüfen weiter.
Ein Methodenheader beweist keine Funktionsberechtigung
Der öffentliche API Security Check meldet begrenzte Antwortmerkmale. Er meldet sich nicht in Ihren Rollen an und prüft keine Export-, Verwaltungs- oder Freigabefunktionen. Auch ein Allow-Header mit GET und POST sagt nicht, welche Identität die jeweiligen Aktionen ausführen darf. HTTP-Befunde lesen erklärt diesen Unterschied; Fehler und Statuscodes helfen bei der dazu passenden Antwortgestaltung.
Quellen und Stand
Quellenstand: 27. September 2026. Die Links stehen zusätzlich bei den jeweils begründeten Aussagen.