Berechtigungen einer Datei-API testen: Ressourcen, Aktionen und Negativfälle

Ein Leitfaden zur Planung, kein API-Vertrag

Authentifizierung und Autorisierung beantworten unterschiedliche Fragen. Bei der Authentifizierung geht es darum, wer eine Anfrage stellt; bei der Autorisierung darum, ob diese Identität eine Aktion ausführen darf. Diese Unterscheidung hilft bei der Strukturierung einer Prüfung, verrät aber nicht von selbst, welche Berechtigungen, Ressourcen oder Antworten eine bestimmte Datei-API unterstützt.

Betrachte die Beispiele in diesem Leitfaden daher als Planungsideen und nicht als verifiziertes Verhalten eines Dienstes. Prüfe vor der Vorbereitung von Testfällen die maßgebliche Dokumentation und die geltende Konfiguration. Dort solltest du nach den verfügbaren Operationen, den Authentifizierungsanforderungen und den Kriterien suchen, anhand derer sich das erwartete Ergebnis bestimmen lässt. Leite Routen, Rollen, Dateieigentum oder Antwortcodes nicht aus dem Verhalten anderer APIs ab.

Auch Verweise auf bestimmte Produkte sind keine allgemeingültigen Regeln. Microsoft dokumentiert ApiCenterMinimalPermissionsPlugin als Tool, mit dem sich prüfen lässt, ob eine Anwendung APIs mit minimalen Berechtigungen aufruft ([Microsoft Learn](https://learn.microsoft.com/es-es/microsoft-cloud/dev/dev-proxy/how-to/check-minimal-api-permissions)). Für Google Drive gibt die Dokumentation an, dass die von der Anwendung benötigten Berechtigungen in der OAuth-Zustimmungskonfiguration angegeben werden müssen ([Google for Developers](https://developers.google.com/workspace/drive/api/guides/api-specific-auth?hl=es-419)). Keine dieser Quellen legt fest, wie eine andere API funktioniert.

• Trenne allgemeine Testideen von den bestätigten Funktionen des Dienstes, den du integrierst.
• Lege die erwarteten Ergebnisse anhand der Produktdokumentation und der aktuellen Konfiguration fest.
• Übertrage Berechtigungen, Tools oder Abläufe von Microsoft oder Google nicht auf eine andere API.

Lege den Umfang fest, bevor du Testfälle vorbereitest

Beginne damit, festzulegen, was du überprüfen möchtest. Notiere, welche Testidentitäten dir zur Verfügung stehen und für die Tests autorisiert sind, welche Testressourcen verfügbar sind und welche Operationen in der Dokumentation aufgeführt werden. Es geht nicht darum, eine hypothetische Matrix zu vervollständigen, sondern überprüfbare Anforderungen in konkrete Testfragen zu übersetzen.

Halte für jede Operation, die du tatsächlich prüfen möchtest, die relevanten Voraussetzungen und die Quelle des erwarteten Kriteriums fest, zum Beispiel einen Abschnitt in der Dokumentation oder eine Dienstkonfiguration. Wenn du noch nicht erklären kannst, warum eine Identität die Aktion ausführen können sollte, kennzeichne das Kriterium als offen, statt es als Tatsache darzustellen.

Setze nicht voraus, dass der Dienst eine Datei als „eigene“ Datei definiert oder den Zugriff über Rollen, Gruppen oder Links organisiert. Wenn solche Konzepte dokumentiert sind, verwende ihre genauen Definitionen. Falls sie nicht erwähnt werden, erfinde sie nicht, um den Plan zu vervollständigen. Eine präzise Beschreibung des Unbekannten ist hilfreicher als eine angenommene Regel.

• Dokumentiere die logische Testidentität, die Ressource, die Aktion und ihre Voraussetzungen.
• Verknüpfe jedes erwartete Ergebnis mit einer überprüfbaren Quelle.
• Halte ausdrücklich fest, welche Fragen die Dokumentation offenlässt, ohne daraus Anforderungen abzuleiten.

Entwirf Testfälle, die konkrete Fragen beantworten

Eine sinnvolle Planung verknüpft jeden Testfall mit einer klar eingegrenzten Frage: Welche Anforderung wird geprüft? Welche Bedingung bleibt unverändert? Welches Ergebnis würde das Kriterium bestätigen oder widerlegen? So lässt sich ein aussagekräftiger Test von einer Anfrage unterscheiden, die lediglich eine kontextlose Antwort liefert.

Wenn der API-Vertrag unterschiedliche Operationen beschreibt, prüfe sie getrennt. Ein beobachtetes Ergebnis für eine Operation belegt nicht automatisch, was bei einer anderen passieren würde. Ebenso solltest du einen Testfall nicht als erlaubt oder abgelehnt einstufen, wenn es keine dokumentierte Grundlage für diese Erwartung gibt.

Wenn du zwei Bedingungen vergleichen möchtest, ändere jeweils nur eine Variable – sofern API-Design und Umgebung dies zulassen. So kannst du beobachtete Unterschiede besser zuordnen. Das ist eine allgemeine Planungsempfehlung; sie setzt weder eine bestimmte API-Struktur noch voraus, dass alle Tests möglich sind.

Halte erwartete und beobachtete Ergebnisse getrennt fest. Wenn die API anders antwortet, als es die Dokumentation erwarten lässt, dokumentiere die Abweichung und die herangezogene Quelle. Bewerte eine konkrete Antwort nicht automatisch als bestanden oder nicht bestanden, wenn der Vertrag dieses Verhalten nicht festlegt.

• Formuliere für jeden Testfall eine überprüfbare Frage.
• Unterscheide Operationen und Bedingungen, statt ein Ergebnis auf die gesamte API zu übertragen.
• Halte Mehrdeutigkeiten im Vertrag als offene Fragen fest.

Bedingtes Beispiel: mit einer anderen Kennung testen

Wenn die Dokumentation Anfragen beschreibt, die Ressourcen anhand einer Kennung identifizieren, und die Umgebung entsprechende Tests zulässt, kannst du einen kontrollierten Versuch mit einer anderen Testressource planen. Dabei lautet die Frage, ob das beobachtete Ergebnis mit dem Kriterium aus Dokumentation und Konfiguration übereinstimmt. Dieses Beispiel besagt nicht, dass alle APIs Kennungen verwenden oder dass sie sich bei der Autorisierung gleich verhalten.

Vergewissere dich vor dem Test, dass du dazu berechtigt bist und die Ressourcen für Tests geeignet sind. Lege im Voraus fest, welche Informationen du beobachten musst, und nimm keine Änderungen vor, die nicht zum Testfall gehören. Könnte die Operation Inhalte verändern, überprüfe anschließend den Ressourcenstatus mit einer vom Dienst erlaubten Methode und dokumentiere nur die notwendigen Belege.

Verwende keine fremde Kennung und keine privaten Daten als Ersatz für eine Testumgebung. Interpretiere eine allgemeine Antwort auch nicht als Beleg für eine bestimmte Richtlinie, wenn der Vertrag eine solche Schlussfolgerung nicht zulässt. Ist das erwartete Verhalten nicht dokumentiert, kann das richtige Ergebnis darin bestehen, die offene Frage festzuhalten und um Klärung zu bitten.

• Führe den Test nur mit autorisierten Zugangsdaten und Ressourcen durch.
• Verwende Testkennungen nur, wenn API und Umgebung diese Art der Prüfung zulassen.
• Vergleiche das Beobachtete mit dem dokumentierten Kriterium, nicht mit einer Annahme.

Dokumentiere Ergebnisse so, dass andere sie überprüfen können

Mit einer klaren Dokumentation lässt sich nachvollziehen, was geprüft wurde, ohne sich auf das Gedächtnis der testenden Person verlassen zu müssen. Halte für jeden Testfall Datum, logische Testidentität, Testressource, Aktion, Voraussetzungen sowie erwartetes und beobachtetes Ergebnis fest. Ergänze den Dokumentationsverweis, der das Kriterium begründet.

Wenn du Anfragen, Antworten oder Screenshots speicherst, prüfe ihren Inhalt, bevor du sie weitergibst. Schwärze Zugangsdaten, Tokens und andere Geheimnisse und vermeide nicht benötigte private Informationen. Ist der Antwortinhalt nicht erforderlich, beschreibe ihn oder verwende einen redigierten Auszug, statt ihn vollständig zu kopieren.

Trenne beobachtete Fakten von Interpretationen. Notiere zum Beispiel die erhaltene Antwort und halte in einem separaten Feld fest, ob sie mit der Beschreibung im Vertrag übereinstimmt. Wenn die Dokumentation eine Abweichung nicht klärt, kennzeichne sie als offene Frage und leite sie an den Anbieter oder die technische Ansprechperson weiter.

• Führe bei jedem Testergebnis das Kriterium und seine Quelle auf.
• Maskiere Geheimnisse und beschränke die Belege auf das für die Prüfung Notwendige.
• Unterscheide Beobachtungen, Schlussfolgerungen und noch offene Fragen.

Ordne die Prüfung den Funktionen von Apification zu

Der Apification-Katalog gibt an, dass Cloud Dateien und Dienste mit Berechtigungen, OTP, externer Authentifizierung, Einschränkungen und Veröffentlichungszeiträumen schützen kann. Außerdem beschreibt er die Freigabe über Links, Benutzer oder Gruppen. Diese Funktionen können dabei helfen, Themen zu erkennen, die bei der Überprüfung einer Cloud-Konfiguration relevant sein könnten. Für sich genommen legen sie jedoch weder ein Autorisierungsmodell für eine API noch das Ergebnis einer konkreten Anfrage fest.

Laut Katalog lassen sich Cloud und seine Dienste außerdem über REST API, OpenAPI, Webhooks, iframe und JavaScript integrieren. Diese Beschreibung bestätigt Integrationsmöglichkeiten auf Produktebene, enthält hier aber keine Endpunkte, Parameter oder erwarteten Antworten. Lies die passende Dokumentation, bevor du diese Funktionen implementierst oder Tests für einen bestimmten Dienst entwirfst.

Halte diese Unterscheidung auch in deinen Schlussfolgerungen aufrecht: Du kannst die vom Katalog bestätigten Funktionen beschreiben und separat darauf hinweisen, welche Autorisierungsdetails in den verfügbaren Informationen nicht aufgeführt sind. So vermeidest du Zusagen zu Kompatibilität oder Verhalten, die noch überprüft werden müssen.

• Nutze den Katalog, um Produktfunktionen zu erkennen, nicht um Details zu Endpunkten abzuleiten.
• Ziehe die spezifische Dokumentation heran, bevor du eine Funktion in einen Integrationstest überführst.
• Weise klar auf noch nicht überprüfte Autorisierungsdetails hin.

Schließe die Prüfung mit einer Checkliste ab

Prüfe vor der Integration oder Weitergabe der Ergebnisse, ob der Umfang für andere verständlich ist und ob die Kriterien belegt sind. Kann ein Test nicht autorisiert ausgeführt werden oder lässt sich sein erwartetes Ergebnis nicht begründen, stelle ihn nicht als abschließende Prüfung dar.

Die folgende Liste dient als redaktionelle Kontrolle des Testplans. Sie ersetzt weder die Dokumentation des Dienstes noch garantiert sie ein Sicherheitsergebnis oder definiert allgemeingültige Antworten für alle APIs. Sie soll dabei helfen, Annahmen und unvollständige Belege zu erkennen, bevor Integrationsentscheidungen getroffen werden.

• Ist jede geprüfte Operation für die konkrete API dokumentiert?
• Stützen sich die erwarteten Ergebnisse auf überprüfbare Dokumentation oder Konfiguration?
• Sind beobachtete Ergebnisse von Schlussfolgerungen getrennt?
• Beschränken sich die Tests auf autorisierte Ressourcen und Zugangsdaten?
• Wurden Geheimnisse und private Daten aus den Belegen entfernt?
• Sind offene Fragen gekennzeichnet, statt durch Annahmen beantwortet zu werden?

Häufige Fragen