Externe APIs sicher einbinden: Antworten, Ausfälle und Daten prüfen

Einen engen Integrationsvertrag festhalten

Beginnen Sie mit einem konkreten Vorgang, beispielsweise der Abfrage des Versandstatus für einen eigenen Auftrag. Notieren Sie Zielservice, Operation, zugelassene Daten, benötigte Rechte und den zuständigen Betreiber. Hinterlegen Sie die Zieladresse in kontrollierter Konfiguration. Ein vom Benutzer übermittelter Host sollte nicht beiläufig zum Backendziel werden; freie Zielwahl verlangt einen eigenen SSRF-Schutz.

Trennen Sie auch innerhalb eines vertrauten Dienstes die Aufgaben. Ein Schlüssel, der Sendungsstatus lesen darf, muss nicht gleichzeitig neue Sendungen anlegen oder Kundendaten exportieren können. Verwenden Sie getrennte Test- und Produktionszugänge und einen geregelten Schlüssellebenszyklus.

Das Vertragsblatt sollte die Version der Partner-API und mögliche Abkündigungen nennen. Klären Sie, ob Erfolg sofort einen abgeschlossenen Vorgang bedeutet oder lediglich die Annahme eines Auftrags. Eine Dokumentation mit dem Wort „success“ ersetzt diese Entscheidung nicht.

OWASP nennt übermäßiges Vertrauen in externe APIs als eigenständiges Risiko. Die Herkunft vom Partner hebt Größen-, Struktur- und Sicherheitsprüfungen nicht auf. OWASP API10:2023.

Eine Antwort in mehreren Schritten prüfen

Zuerst muss der Transportvertrag passen: erwartetes Ziel, funktionierende Zertifikatsprüfung und eine Antwort innerhalb des festgelegten Budgets. Die gemeinsamen Grundlagen erklärt der TLS-Ratgeber. Schalten Sie die Zertifikatsprüfung nicht ab, um eine gestörte Integration scheinbar zu reparieren.

Danach folgen Status, Inhaltstyp, begrenztes Einlesen und die Datenstruktur. Ein 200-Status kann eine fachliche Fehlermeldung enthalten; ein 202-Status bestätigt häufig nur die Annahme. Welche Statuscodes Ihr Partner für welchen Zustand verwendet, muss dessen Vertrag sagen. Eine HTML-Störungsseite ist nicht einfach eine leere gültige JSON-Antwort.

Ein synthetischer Antwortausschnitt könnte lauten:

{
  "shipment_id": "demo-shipment-42",
  "client_reference": "demo-order-17",
  "state": "in_transit",
  "parcel_count": 2
}

Ein Parser kann feststellen, dass dies gültiges JSON ist. Für eine sinnvolle Verwendung müssen Sie zusätzlich prüfen, ob die Felder die vereinbarten Typen und Grenzen haben, die Referenz zu Ihrem angefragten Auftrag gehört und die Sendung in Ihrer eigenen Zuordnung zum richtigen Mandanten steht. Ein frei geliefertes Feld „tenant“ würde diese interne Zuordnung nicht ersetzen.

Wie Sie solche Grenzen am eigenen API-Eingang gestalten, erläutert Eingaben validieren. Für Partnerantworten gilt dieselbe Vertrauensgrenze an einem anderen Ort. Entscheiden Sie bei zusätzlichen Feldern bewusst: Ein Vertrag kann erlauben, unbekannte optionale Felder zu ignorieren. Das ist etwas anderes, als neue Zustandswerte oder privilegierte Anweisungen ungeprüft auszuführen.

Zeit, Größe und parallele Arbeit begrenzen

Ein Partnerausfall darf nicht alle verfügbaren Arbeitsplätze Ihrer API binden. Definieren Sie daher ein Gesamtzeitbudget und, soweit Ihr Client das unterstützt, sinnvolle Teilgrenzen für Verbindungsaufbau und Antwort. Begrenzen Sie Daten beim Einlesen, bevor ein vollständiger großer Body im Speicher liegt. Berücksichtigen Sie komprimierte Antworten und die maximale Zahl parallel laufender Vorgänge.

Die genauen Zahlen folgen aus der Funktion. Eine interaktive Statusanzeige darf nach einer klaren Frist „derzeit nicht verfügbar“ melden. Ein wichtiger Hintergrundauftrag kann dagegen dauerhaft gespeichert und später weiterbearbeitet werden. Eine unbegrenzte Warteschlange löst keines der beiden Probleme.

Ordnen Sie Wiederholungen einer verantwortlichen Schicht zu. Wenn SDK, Gateway und Ihr Code jeweils mehrmals wiederholen, wachsen Verzögerung und Last. Ein gemeinsames Budget begrenzt dieses Verhalten. Microsoft: Retry pattern.

Für schreibende Aufrufe gilt zusätzlich: Ein lokal abgebrochener Request hebt eine mögliche Wirkung beim Partner nicht auf. Der Ratgeber zu Retries und Idempotenz erklärt, wie derselbe Auftrag wiedererkannt oder sein Ausgang geklärt wird.

Daten gezielt senden und Weiterleitungen kontrollieren

Senden Sie nur Felder, die für die vereinbarte Operation benötigt werden. Übergeben Sie nicht das gesamte interne Kundenobjekt, nur weil es bequem serialisierbar ist. Für einen Statusabruf sind beispielsweise die Partnerreferenz und erforderliche Zugangsinformationen relevant; interne Notizen oder andere Kundenbeziehungen normalerweise nicht.

Prüfen Sie im HTTP-Client, ob und wie er Redirects verfolgt. Die Weiterleitung auf einen anderen Host kann auch sensible Nutzlast betreffen, nicht nur einen Authorization-Header. Bei einer fest vereinbarten Partner-API können unerwartete Redirects einen Konfigurationsfehler oder eine Vertragsänderung anzeigen. Stoppen und klären ist dann eine sinnvolle Ausgangsregel.

Achten Sie auch auf Antworten, die neue URLs für Folgeschritte liefern. Diese sind wiederum Eingaben in Ihren Abrufweg. Eine vom Partner gelieferte Downloadadresse benötigt eine passende Zielpolitik; sie darf nicht ungeprüft beliebige interne Ziele öffnen. Das gilt auch bei einem kompromittierten oder falsch konfigurierten Partner.

Einen sicheren Ausweichzustand wählen

Ein Fallback ist ein ausdrücklich entworfener Ersatzweg. Er darf keine Berechtigung erfinden und keinen unklaren Schreibauftrag als erledigt darstellen.

Gecachte Daten müssen zu Identität, Mandant und zulässiger Nutzung passen. Ein einziger Cacheeintrag für unterschiedliche Kunden kann vertrauliche Ergebnisse vermischen. Die HTTP-Grundlagen stehen im Cache-Control-Ratgeber; die Anwendungszuordnung ist zusätzlich Ihre Aufgabe.

Integration mit einem simulierten Partner prüfen

Bauen Sie zunächst einen kleinen lokalen Stub, also einen kontrollierten Ersatz für die Partnerantworten. Verwenden Sie ausschließlich erfundene Aufträge. Er muss nicht das gesamte Fremdprodukt nachbauen: Für Ihren Vertrag genügen normale Antwort, ungültige Struktur, unerwarteter Status, falsche Referenz, zu große Daten, Verzögerung und ein unklarer Ausgang nach einer angenommenen Aktion.

Prüfen Sie, dass bei abgewiesenen Antworten keine fachliche Folgeaktion ausgelöst wird. Der Nachweis ist der gespeicherte Zustand Ihrer Anwendung und gegebenenfalls die Zahl ausgeführter Dummy-Aktionen. Ein passender Fehlertext allein sagt darüber zu wenig.

Vor einer Versions- oder Schlüsselumstellung vergleichen Sie dieselben Vertragsfälle mit dem neuen Weg. Bereiten Sie die Rücknahme der Konfiguration vor und halten Sie offene Aufträge nachvollziehbar. Eine Rückkehr zur alten API-Version setzt voraus, dass diese noch unterstützt und für die betroffenen Daten geeignet ist; eine absichtlich stillgelegte unsichere Variante sollte nicht unbemerkt wieder aktiviert werden.

Das JSON-Beispiel ist synthetisch; ein echter Partner oder ein produktiver Zugang wurde dafür nicht aufgerufen. Der API Security Check prüft weder Ihren ausgehenden Client noch die fachliche Verwendung fremder Antworten. Inventar und Versionierung halten die Abhängigkeit aktuell, Logging und Monitoring verbinden Vertragsfehler mit einer zuständigen Reaktion.

Passende nächste Schritte