In den meisten Organisationen lebt das API-Inventar in Anwendungsdokumentation, veralteten Schema-Dateien oder von einzelnen Teams gepflegten Listen. Aber Anwendungen ändern sich mit jedem Release: Neue Endpoints werden hinzugefügt, alte werden vergessen, Testpfade bleiben in der Produktion. Sicherheitsteams erfahren typischerweise, welche APIs im echten Traffic aktiv sind, nach den Anwendungsteams.
Diese Lücke verstärkt das Shadow-API- und Zombie-Endpoint-Risiko. Ein undokumentierter Endpoint kann vollständig außerhalb der WAF-Policy liegen; ein Endpoint, der nicht mehr in Betrieb sein sollte, kann immer noch erreichbar sein. Aus der Sicht eines Angreifers sind diese Bereiche wenig sichtbar, schwach geschützt und es lohnt sich, sie zu sondieren.
Sich allein auf eine extern bereitgestellte Schema-Datei zu verlassen ist ebenfalls unzureichend. Wenn das Schema nicht aktuell ist, stimmt es nicht mit dem echten Traffic überein. Das Anwendungsteam kann einen Endpoint geändert haben, ohne das Schema zu aktualisieren, oder ein Pfad, der nie im Schema erscheint, kann in der Produktion laufen. In diesem Fall basiert die Schutzpolicy auf einer veralteten Annahme statt auf echtem Anwendungsverhalten.
Das traditionelle negative Sicherheitsmodell löst dieses Problem nicht allein. Das Blockieren bekannter Angriffsmuster ist wichtig, aber die eigentliche Stärke in der API-Sicherheit liegt darin, die erlaubten Methoden, Header, Parameter, MIME-Typen und Body-Felder explizit zu definieren. Ohne positive Sicherheit können unbekannte, aber scheinbar gültige bösartige Requests unangefochten passieren.
TR7 API Discovery & Schema schließt diese Lücke: es erlernt API-Verhalten aus echtem Traffic, unterstützt Schema-Generierung aus dem OpenAPI-Flow oder Regel-Generierung aus einem Schema und bringt positive Sicherheitskontrollen inline.
TR7 wendet API Discovery zusammen mit Traffic-Lernen, positivem Schema, Größen- und Tiefenlimits sowie feldbasierter Validierung an.
TR7 kann Pfad- und Methodenverhalten aus echtem Traffic erlernen und Endpoint-Muster erstellen. Pfade mit variablen IDs, Daten oder Tokens werden zu einem besser lesbaren API-Inventar normalisiert.
Allow-Lists können für Methoden, Header, Query-Parameter, JSON-Keys, XML-Elemente, Formularfelder und MIME-Typen definiert werden. Statt nur nach bekannten schlechten Mustern zu suchen, erklärt die Policy explizit das erwartete API-Verhalten.
Limits wie Pfadlänge, Pfadtiefe, Header-Anzahl, Query-Anzahl, JSON-Tiefe, XML-Tiefe und rohe Body-Größe können alle angewendet werden. Diese Limits stellen sicher, dass überdimensionierte oder übermäßig komplexe Requests geprüft werden, bevor sie das Backend erreichen.
Regex-Validierung kann für jeden Header, Query-Parameter, Formularfeld oder Body-Feld definiert werden. E-Mail-, Telefon-, ID-, Ländercode- oder dienstspezifische Formate werden auf Feldebene geprüft.
API Discovery & Schema verwandelt das erlernte Endpoint-Inventar in durchsetzbare positive Sicherheitsregeln.
TR7 kann Pfad- und Methodeninformationen aus eingehenden Requests analysieren, um Endpoint-Muster abzuleiten. Pfade wie `/api/users/123` und `/api/users/456` können unter einem einzigen logischen Muster gruppiert werden. Dieser Ansatz macht Endpoints sichtbar, die nicht in der Dokumentation stehen, aber aktiv in der Produktion laufen. Das API-Inventar basiert auf echtem Traffic-Verhalten, nicht auf Annahmen.
TR7 ist positioniert, um einen Workflow zur Generierung OpenAPI-kompatibler Schemas aus erlerntem API-Verhalten zu unterstützen. In umgekehrter Richtung können TR7-Regeln aus einem vom Benutzer bereitgestellten OpenAPI-Schema generiert werden. Dieses bidirektionale Modell reduziert die Lücke zwischen echtem Traffic und dem dokumentierten API-Vertrag. Der Operator verwendet dieselbe Plattform für Discovery und Enforcement.
Die Liste erlaubter Methoden — GET, POST, PUT, DELETE, PATCH und andere — kann pro Endpoint definiert werden. Wenn beispielsweise ein POST an einen Endpoint gesendet wird, der nur GET erwartet, kann dieses Verhalten als Policy-Verletzung behandelt werden. Eine methodenbasierte Allow-List ist eine einfache, aber effektive positive Sicherheitsschicht. Falsches oder missbräuchliches Endpoint-Verhalten wird früher erkannt.
Erlaubte Header und Query-Parameter können pro Endpoint definiert werden. Für jedes Feld können Name, Wertformat und Regex-Validierung angewendet werden. Unerwartete Header oder Parameter können mit einem Sicherheits-Score, Alert oder Block verknüpft werden. Daten außerhalb des API-Vertrags werden daher nicht ungeprüft an das Backend weitergegeben.
TR7 kann Allow-Lists auf der Ebene von JSON-Keys, XML-Elementen und Formularfeldern erstellen. Pflichtfelder können mit mustArgs definiert werden; unbekannte Felder können aus der erlaubten Liste ausgeschlossen werden. Diese Struktur beschreibt den erwarteten Request-Body, statt nur nach Angriffssignaturen zu suchen. API-Endpoints werden auf eine Weise geschützt, die näher an ihrem eigenen Vertrag bleibt.
Allow-Lists für erlaubte MIME-Typen können für Formular- und rohen Body definiert werden. Das Senden von Daten an einen JSON-erwartenden Endpoint mit einem anderen Content-Type kann als Policy-Verletzung behandelt werden. Diese Kontrolle ist besonders wichtig für Datei-Upload- oder formularbasierte APIs. Content-Type wird zu einem direkten Eingang in die Sicherheitsentscheidung.
Gesamtgrößenlimits können für Header, Query-Strings, Formulare, JSON, XML und rohen Body angewendet werden. JSON- und XML-Verschachtelungstiefe-Kontrollen verhindern, dass übermäßig tiefe Payloads den Parser und das Backend belasten. Limits wie Key-Anzahl, Wert-Anzahl, Feldlänge und Duplikatanzahl können ebenfalls definiert werden. Diese Kontrollen schaffen eine Schutzgrenze sowohl für Sicherheit als auch für Performance.
Einige Endpoints müssen möglicherweise überhaupt keine JSON- oder XML-Bodies akzeptieren. TR7 kann Kontrollen bereitstellen, um die JSON- oder XML-Body-Nutzung auf einer Pro-Endpoint-Basis vollständig zu deaktivieren. Dies verhindert, dass unerwartete Body-Formate das Backend erreichen. Es ist besonders effektiv für einfache GET-Endpoints und Dienste, die keine Nicht-Formular-Transaktionen akzeptieren.
Regex-basierte Validierung kann für jeden Header, Query-Parameter, Formularfeld oder Body-Feld angewendet werden. E-Mail, Telefon, UUID, numerische ID, Ländercode oder organisationsspezifische Formate werden auf diese Weise geprüft. Formatfremde Werte werden nicht der Anwendung überlassen — sie werden am Edge abgefangen. Dieses Modell bringt die Datenfomatdimension des API-Vertrags in die Sicherheitspolicy ein.
Aus Traffic erlernte Endpoints können gegen die bestehende dokumentierte API-Liste verglichen werden. Aktive Endpoints, die nicht in der Dokumentation stehen, können als Shadow-API-Kandidaten markiert werden; Endpoints, die keinen Traffic mehr empfangen sollten, es aber tun, können als Zombie-Endpoint-Kandidaten markiert werden. Diese Empfehlungen werden als Lernvorschläge für den Operator zur Überprüfung präsentiert, nicht als absolute Durchsetzungsentscheidungen. Sicherheitsteams können die echte API-Oberfläche schneller kartieren.
Im Laufe der Zeit können neue JSON-Keys, neue Query-Parameter oder andere Methodennutzung auftauchen. TR7 kann Unterschiede zwischen erlerntem Verhalten und der aktuellen Schema-Policy sichtbar machen. Diese Unterschiede können eine Anwendungsversionsänderung, einen fehlerhaft funktionierenden Client oder einen Missbrauchsversuch signalisieren. Der Operator kann die Änderung akzeptieren und zum Schema hinzufügen oder sie als Policy-Verletzung behandeln.
API Discovery hilft dabei, zu berichten, welche Endpoints in einem bestimmten Zeitraum aktiv waren. Fragen wie „Welche Endpoints haben in den letzten 30 Tagen Traffic empfangen?“ sind für Sicherheits- und Compliance-Teams wichtig. Ein traffic-basiertes Inventar liefert eine realistischere Audit-Basislinie als ein statisches Dokument. Die Organisation überwacht ihre API-Oberfläche gegenüber Live-Verhalten.
API-Discovery- und Schema-Kontrollen arbeiten über Pfad-, Query-, Header-, Formular-, JSON-, XML- und rohe Bereiche.
TR7-Schema-Kontrollen decken Pfad-, Query-, Header-, Formular-, JSON-, XML- und rohe Felder ab. Jeder Bereich kann seine eigenen Limits, Allow-Lists und Validierungsregeln tragen. API-Sicherheit wird daher über die vollständige Request-Oberfläche definiert, nicht nur den Body.
Schema-Regeln können mit verschiedenen Typen wie complexInput, regex, numeric, boolean und enumSelect definiert werden. Einfache Ein-/Aus-Kontrollen und detaillierte Feldlisten werden innerhalb derselben DSL verwaltet. Der Operator wählt den Regeltyp basierend auf dem API-Verhalten.
Regeln können auf verschiedenen Zielebenen angewendet werden: Web-Anwendung, API-Endpoint und Anwendungsserver. Dies ermöglicht eine Unterscheidung zwischen einer allgemeinen Service-Policy und einem Schema, das für einen einzelnen Endpoint spezifisch ist. Die Wahl des richtigen Bereichs ergibt eine Policy mit weniger Wiederholungen und einem klareren Wirkungsbereich.
Das Lernmodell kann Knoten pro Pfad, Häufigkeitszähler und Kindpfadinformationen halten. Zusammenfassende Informationen können nach Host oder Service-Gruppe extrahiert werden. Diese Struktur hilft zu verstehen, welche Teile der API-Oberfläche Traffic-intensiv, spärlich oder neu auftauchend sind.
Erlernte Änderungen können zur Admin-Genehmigung eingereicht werden, statt automatisch angewendet zu werden. Der Operator überprüft Vorschläge für neue Endpoints, neue Felder oder neue Muster und wandelt die entsprechenden in Policy um. Dieses Modell positioniert das Lernen als geführte Entscheidungsunterstützung statt als unkontrollierte Automatisierung.
Historische Log-Dateien können im Batch analysiert werden, um API-Verhalten rückwirkend abzuleiten. Das bedeutet, dass der Discovery-Prozess nicht auf Live-Traffic beschränkt ist. Frühere Traffic-Perioden, Kampagnenfenster oder Incident-Momente können separat untersucht werden.
Sicherheitsteams können die aus echtem Traffic erlernte Endpoint-Liste gegen die bestehende API-Dokumentation vergleichen. Aktive Pfade, die nicht in der Dokumentation vorhanden sind, werden als Shadow-API-Kandidaten zur Überprüfung aufgenommen.
Microservice-Teams können das Endpoint-Verhalten jedes Diensts aus Traffic sehen, ohne auf manuelle Dokumentation warten zu müssen. TR7 hilft dabei, das pfad-und-methoden-basierte Inventar in eine Sicherheitspolicy zu überführen.
Compliance-Teams können berichten, welche Endpoints in einem bestimmten Zeitraum aktiv waren. Dies macht die API-Oberfläche, die Daten verarbeitet, während eines Audits klarer sichtbar.
Wenn Endpoints, die für Tests oder Staging geöffnet wurden, im Produktions-Traffic erscheinen, können sie in den Lernempfehlungen auffallen. Das Operations-Team kann sie dann schließen, einschränken oder unter die richtige Sicherheitspolicy stellen.
Traffic-basiertes Endpoint-Inventar, Shadow-API-Sichtbarkeit und positive Schema-Regeln — wir zeigen Ihnen ein Live-Setup auf Ihren eigenen Diensten.