Was zum API-Inventar gehört
Erfassen Sie den Bestand aus eigenen verlässlichen Quellen: Routing- und Gatewaykonfiguration, Deploymentdefinitionen, API-Dokumentation, Dienstregister sowie vorhandene Nutzungsprotokolle. Keine dieser Quellen allein beweist Vollständigkeit. Eine vergessene Route kann im Code existieren, aber in der Dokumentation fehlen; eine stillgelegte Version kann noch über einen zweiten Host erreichbar sein.
OWASP nennt unvollständige Inventare und vergessene Versionen als eigenes API-Risiko. Auch Datenflüsse zu Dritten und unterschiedliche Umgebungen gehören zur Betrachtung. OWASP API9:2023.
Ein kleines Team braucht dafür nicht zwingend ein neues Werkzeug. Eine gepflegte Zuordnung kann zunächst so aussehen:
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Feld | Beispielinhalt und Zweck |
|---|---|
| Host und Umgebung | api.example.invalid, Produktion; Staging separat führen |
| Operation und Version | POST /v1/exports; zuständiger Dienst |
| Erreichbarkeit und Zugang | Öffentlicher Gatewayweg; Anmeldung erforderlich; direkter Dienstzugriff gesondert geregelt |
| Daten und Wirkung | Eigene Exportdaten, Hintergrundauftrag, keine fremden Mandanten |
| Verantwortlichkeit | Zuständige Entwicklung und Betriebsvertretung |
| Verbraucher/Abhängigkeit | Eigener Client, benannte Partnerintegration, nachgelagerter Speicher |
| Lebenszyklus | Aktiv, in Migration oder stillgelegt; nächster Prüftermin und Beleg |
Die Werte sind erfunden und nicht abrufbar. Ihr Inventar sollte keine Zugangswerte enthalten. Verweise auf zuständige Systeme und Schlüsselkennungen genügen; Geheimnisse bleiben in ihrem vorgesehenen Speicher.
Dokumentation und tatsächlichen Betrieb abgleichen
OpenAPI beschreibt Operationen, Parameter und Antworten. Diese Beschreibung hilft beim Vertragsabgleich, schaltet aber keine Route ab. Auch das Feld deprecated an einer Operation ist zunächst eine Kennzeichnung. OpenAPI 3.2.0: Operation Object.
Vergleichen Sie die dokumentierten Operationen mit dem tatsächlichen Routing und den freigegebenen Testfällen. Klären Sie Abweichungen konkret: Ist der undokumentierte Weg beabsichtigt? Welche Anmeldung und welche Rechte gelten dort? Erhält eine ältere Version dieselben Sicherheitskorrekturen wie die neue?
Eine Versionsnummer beantwortet diese Fragen nicht. Sie kann die API, eine Dokumentausgabe oder ein deploytes Softwarepaket bezeichnen. Legen Sie fest, welches Versionssignal der Client tatsächlich auswählt. Mehrere gleichzeitig gültige Auswahlwege, etwa Host plus Pfad plus Header, erhöhen den Pflegeaufwand und müssen widerspruchsfrei sein.
Eine Änderung, die „nur ein Feld ergänzt“, kann für konkrete Clients trotzdem relevant sein, etwa bei strenger Auswertung oder neuen Zustandswerten. Prüfen Sie daher Kompatibilität am Vertrag und an repräsentativen Verbrauchern. Semantische Versionsnummern ersetzen diese Prüfung nicht.
Die Migration als betreuten Zeitraum planen
Benennen Sie zuerst den Ersatz und die notwendige Clientänderung. Dazu gehören Unterschiede bei Rechten, Datenformaten, Fehlerantworten und Nebenwirkungen. Ein Beispielaufruf für die neue Route hilft wenig, wenn nicht klar ist, ob ein offener Auftrag über beide Versionen denselben Zustand betrifft.
Identifizieren Sie betroffene eigene Clients und vereinbarte Partner anhand vorhandener Nutzungsdaten und Zuständigkeiten. Kein beobachteter Zugriff in einem kurzen Zeitraum beweist keine weitere Nutzung: monatliche Aufgaben oder pausierte Integrationen können später zurückkehren. Dokumentieren Sie deshalb den Beobachtungszeitraum und die verbleibende Unsicherheit.
Während der Migration bleibt die alte Version ein echter Teil des Produkts. Geben Sie ihr nicht automatisch schwächere Anmeldung, fehlende Mengenbegrenzung oder ungepflegte Bibliotheken. Falls sie eine konkrete Sicherheitslücke enthält, muss die Abwägung zwischen Reparatur, Einschränkung und früherer Abschaltung ausdrücklich erfolgen.
Vereinbaren Sie einen Zeitpunkt, Verantwortliche und einen Rücknahmeweg. Eine Verlängerung des Übergangs ist eine Entscheidung mit neuem Termin und fortgesetzter Pflege. Sie sollte kein stilles Wiederöffnen eines bereits aufgegebenen Dienstes sein.
Deprecation und Sunset unterscheiden
Deprecation informiert darüber, dass eine Ressource als veraltet gilt oder künftig so eingestuft wird. Sunset kündigt an, dass sie zu einem Zeitpunkt voraussichtlich nicht mehr wie bisher verfügbar sein wird. Beide Angaben informieren; die technische Stilllegung erfolgt an anderer Stelle.
Ein selbst erstelltes Beispiel für einen geplanten Übergang:
Deprecation: @1790812800
Sunset: Thu, 01 Apr 2027 00:00:00 GMT
Link: <https://docs.example.invalid/migration/v2>; rel="deprecation"
Hier beginnt die Abkündigung am 1. Oktober 2026 um 00:00 UTC. Der angekündigte Sunset liegt am 1. April 2027 um 00:00 UTC. Die Dokumentationsadresse ist nur ein Beispiel.
Deprecation verwendet nach RFC 9745 einen Structured-Field-Datumswert mit vorangestelltem @; Sunset verwendet ein HTTP-Datum. RFC 9745 ist ein Proposed Standard von März 2025. RFC 8594 beschreibt Sunset als Informational RFC. Wenn beide Angaben eingesetzt werden, darf Sunset nicht vor dem Deprecation-Datum liegen. RFC 9745, Abschnitte 2–5, RFC 8594, Abschnitte 3–5.
Die Angabe bezieht sich zunächst auf die antwortende Ressource. Soll sie eine gesamte Version betreffen, muss der erweiterte Geltungsbereich klar dokumentiert sein. Ein Header an der Startadresse setzt nicht automatisch alle anderen Endpunkte außer Betrieb. Ebenso ist Sunset keine Garantie, dass die Ressource bis genau zu diesem Zeitpunkt verfügbar ist. Clients sollten den Migrationsvertrag lesen und mögliche Ausfälle ohnehin behandeln.
Die Stilllegung durch den tatsächlichen Weg belegen
Entfernen oder sperren Sie die alte Operation an den relevanten Zugangspunkten nach dem geplanten Vertrag. Prüfen Sie dabei alternative Hosts, Gatewayrouten, direkte Dienstwege, frühere Dokumentations-/Debugzugänge und Hintergrundverbraucher aus Ihrem Inventar. Für einen bewusst entfallenen Endpunkt kann beispielsweise 410 sinnvoll sein; die passende Antwort hängt vom Vertrag und vom verbleibenden Betrieb ab. Es gibt keinen für jede Stilllegung vorgeschriebenen Einzelstatus.
DNS allein abzuschalten genügt nicht als allgemeiner Beleg. Ein anderer Host oder eine direkte Route kann dieselbe Anwendung weiterhin erreichen. Ebenso sagt ein 404 an einer einzigen öffentlichen URL nichts über alte Verwaltungswege aus.
Erbringen Sie den Nachweis mit den vorher festgelegten eigenen Kontrollfällen und der Konfiguration: Die alte Wirkung ist nicht mehr erreichbar, die neue Route funktioniert für berechtigte Testnutzer, offene Aufträge bleiben geklärt und die benötigten Schutzregeln gelten weiter. Halten Sie Prüfzeitpunkt, Umgebung und bewusst nicht geprüfte Wege fest. Für dieses Manuskript wurde keine reale Stilllegung durchgeführt.
Eine Rücknahme benötigt einen engen Umfang. Falls die neue Version fachlich fehlschlägt, kann eine geprüfte Vorgängerversion zeitweise nötig sein. Aktivieren Sie dabei weder widerrufene Schlüssel noch die Schwachstelle wieder, die zur Stilllegung geführt hat. Gegebenenfalls bleibt eine einzelne Funktion ausgesetzt, bis ein sicherer Ersatz verfügbar ist.
Bibliotheken, Images und Laufzeiten mitpflegen
Zum sicheren Betrieb gehören nicht nur Ihre sichtbaren API-Versionen. HTTP-Client, Framework, Parser, Laufzeit und Containerbasis haben eigene Versions- und Pflegezyklen. Erfassen Sie die tatsächlich ausgelieferten Versionen einschließlich indirekter Abhängigkeiten, soweit Ihre Werkzeuge dies zuverlässig liefern, und benennen Sie eine zuständige Person für Sicherheitshinweise.
Ordnen Sie einen Hinweis dem verwendeten Paket, seiner Herkunft, Version und betroffenen Funktion zu. Eine im Header sichtbare Versionszeichenfolge ist dafür nur ein Hinweis. Gepflegte Distributionen können Korrekturen zurückportieren; umgekehrt beweist ein fehlender Banner keine aktuelle Software.
Planen Sie Sicherheitsupdates mit gezielten Tests der berührten Funktionen, einem freigegebenen Auslieferungsweg und einer bekannten Rücknahmeoption. Wenn eine verwundbare Funktion vorübergehend deaktiviert wird, halten Sie Maßnahme, Rest und Endtermin fest. OWASP beschreibt solche kontextabhängigen Wege ausdrücklich als Empfehlungen, nicht als Rezept mit garantierter Wirkung. OWASP: Vulnerable Dependency Management.
Ein Pflegeereignis braucht einen nachvollziehbaren Abschluss
Verknüpfen Sie Versionswechsel und Abschaltung mit Ihrem Logging und Monitoring: Wer nutzt den alten Weg noch, welche Fehler entstehen nach dem Wechsel und wer reagiert? Halten Sie das Inventar beim Release aktuell, statt es erst beim nächsten Vorfall neu zusammenzusuchen.
Der API Security Check führt keine Endpunktinventur und keinen vollständigen Abhängigkeits- oder CVE-Audit durch. Ein öffentlicher Antwortbefund kann einen einzelnen Ausgangspunkt liefern; Bestand, Pflege und Stilllegung benötigen Ihre eigenen Konfigurations- und Betriebsbelege. Die Prüfung eigener API-Zusagen hilft beim Zusammenstellen passender Kontrollfälle.
Quellen und Stand
Quellenstand: 27. September 2026. Die Links stehen zusätzlich bei den jeweils begründeten Aussagen.