Jede pull request Das Hinzufügen oder Ändern eines Endpunkts verändert die Angriffsfläche Ihrer API. Die meisten API-Sicherheitstools bemerken dies erst, wenn der Endpunkt aktiv ist und bereits Datenverkehr verarbeitet. Dann ist die Behebung nicht mehr mit einer einzigen Codezeile im Rahmen einer Codeüberprüfung zu bewältigen, sondern erfordert eine Reaktion auf einen Sicherheitsvorfall.
API-Sicherheit ist die Praxis, die Risiken zu finden und zu beheben, die sich aus der Art und Weise ergeben, wie eine Anwendung ihre Endpunkte bereitstellt: wer sie aufrufen kann, welche Daten sie zurückgeben und ob sie das tun, was in der Dokumentation beschrieben ist.
Die meisten Tools, die für dieses Problem entwickelt wurden, testen die API zur Laufzeit, von außen, genau wie ein Angreifer es tun würde. Dieser Ansatz funktioniert, aber erst nach der Bereitstellung der API. Xygeni wählt den früheren Weg: Es liest Ihren Quellcode und Ihre API-Spezifikation, bevor überhaupt eine einzige Anfrage den Endpunkt erreicht.
Die vier Methoden zum Testen einer API und was jede einzelne beantwortet
Die meisten ausgereiften Programme nutzen mehr als eines dieser Programme:
- Statische Prüfung Vor der Bereitstellung analysiert es Quellcode und API-Spezifikationen. Es beantwortet die Frage: „Was haben wir gerade offengelegt?“ Diesem Ansatz geht es in diesem Artikel.
- Dynamisches Testen (DAST) Es sendet echten Datenverkehr an eine laufende API und beobachtet deren Reaktion. Es beantwortet die Frage: „Was ist aktuell erreichbar und ausnutzbar?“
- Fuzzing Es leitet fehlerhafte oder unerwartete Eingaben an Endpunkte weiter, um Abstürze und Grenzfallfehler aufzudecken. Es beantwortet die Frage: „Was führt zu Fehlern bei Eingaben, die wir nicht vorhergesehen haben?“
- Manuelle Penetrationstests Es ergänzt die menschliche Urteilsfähigkeit, um Logikfehler aufzudecken, die automatisierte Tools übersehen. Es beantwortet die Frage: „Welche Verbindungen würde ein intelligenter Angreifer herstellen?“
Keines dieser Programme ersetzt das andere. Sie beantworten unterschiedliche Fragen zu unterschiedlichen Zeitpunkten im Lebenszyklus, und die Lücke, die die meisten Programme aufweisen, ist die erste.
Warum die meisten API-Sicherheitstools das Risiko zu spät erkennen
API-Sicherheitstests zur Laufzeit senden Datenverkehr an eine laufende Anwendung und beobachten deren Reaktion. Dies ist eine legitime und notwendige Sicherheitsebene. Konstruktionsbedingt ist sie jedoch ein nachlaufender Indikator: Ein Endpunkt muss existieren, bereitgestellt und erreichbar sein, bevor ein Laufzeitscanner etwas darüber aussagen kann. Die gefundenen Schwachstellen waren bereits während der gesamten Scandauer offengelegt.
Hinter diesem Timing-Problem verbirgt sich eine weitere Lücke. Laufzeittools können nur testen, was ihnen bekannt ist. Wenn ein Endpunkt nie dokumentiert wurde oder die OpenAPI-Spezifikation veraltet ist, sobald jemand eine neue Route veröffentlicht hat, kann ein Laufzeitscanner nicht feststellen, dass dieser Endpunkt existiert. Er testet die Karte, nicht das Gebiet.
Statische API-Sicherheitstests schließen beide Lücken, indem sie die Prüfung dorthin verlagern, wo der Endpunkt definiert ist: in Ihren Code und Ihre API-Spezifikation, vor der Bereitstellung. pull request das einen Endpunkt einführt, ist das pull request das seine Risiken offenbart.
Was statische API-Sicherheit wirklich bedeutet
Xygeni erstellt Ihr API-Inventar aus zwei Quellen: dem Quellcode Ihrer Anwendung und Ihren API-Spezifikationen, einschließlich OpenAPI und Swagger.
Eine reine Spezifikationsübersicht zeigt die Endpunkte, die jemand dokumentiert hat. Eine reine Codeübersicht zeigt, was existiert, aber nicht unbedingt, wie es verwendet werden soll. Die Lektüre beider Übersichten liefert das vollständige Bild: die von Ihren Teams dokumentierten Endpunkte und diejenigen, die niemand dokumentiert hat.
Dieses Inventar bildet das Fundament, auf dem alles andere aufbaut:
- Gesamtzahl der entdeckten APIs und der gefährdeten Assets im Vergleich zu einem Basiswert
- Endpunkte aufgeschlüsselt nach HTTP-Methode
- Nach Diensten gruppierte Probleme
- Jeder Endpunkt mit seiner Methode, seinem Pfad, seinem Dienst, seinem Modul, seinem Authentifizierungsstatus und seiner Risikobewertung
Ihre technischen Leiter sehen die Struktur Ihrer API-Oberfläche, ohne ein einziges Ticket öffnen zu müssen.
Jeder von Xygeni gefundene Endpunkt, mit seiner Methode, seinem Authentifizierungsstatus und seiner Risikobewertung, wurde aus Code und Spezifikation gemeinsam erstellt.
Production note Schneiden Sie das AI-Triage-Panel aus einem beliebigen API-Security-Screenshot aus.
Entspricht den OWASP API Security Top 10
Die Ergebnisse spiegeln das Framework wider, das Ihre Sicherheitsteams und Auditoren bereits verwenden. Xygeni erkennt Risiken im gesamten OWASP API Security-Standard. Top 10 (2023):
Eine Kategorie fehlt bewusst. API6, „Uneingeschränkter Zugriff auf sensible Geschäftsprozesse“, erfordert ein Verständnis dafür, was ein Geschäftsprozess eigentlich ermöglichen soll, und kein statischer Analysator kann dies zuverlässig erkennen. Jeder Anbieter, der etwas anderes behauptet, verkauft Ihnen lediglich eine leere Klausel. Diese Kategorie bleibt in Ihrer Verantwortung für die Bedrohungsmodellierung und Ihre Penetrationstester.
Nicht alle Ergebnisse sind gleichwertig: Datensensitivität und toxische Kombinationen
Eine einfache Liste von Ergebnissen behandelt einen nicht authentifizierten Health-Check-Endpunkt genauso wie einen nicht authentifizierten Endpunkt, der Kundendatensätze zurückgibt. Es handelt sich dabei nicht um dasselbe Problem, und ein Priorisierungsmodell, das beide gleich bewertet, führt dazu, dass Ihre Teams die Liste ignorieren.
Xygeni klassifiziert die von jedem Endpunkt verarbeiteten Daten, kennzeichnet PII, PCI und PHI in Anfrageparametern und Antworten und verknüpft dies mit dem Authentifizierungsstatus des Endpunkts.
Es korreliert außerdem Befunde, die denselben Endpunkt betreffen, und erhöht die Schwere des Problems, wenn sie sich häufen. Ein Datenleck personenbezogener Daten in einer Antwort ist an sich schon ein schwerwiegender Befund. Dasselbe Datenleck an einem Endpunkt, der keine Authentifizierung erfordert, ist kritisch, und die Plattform bewertet es entsprechend, anstatt die Verbindung manuell entdecken zu lassen.
Zombie- und verwaiste Endpunkte: Die Diskrepanz zwischen Code und Spezifikation
Da Xygeni Ihren Code und Ihre API-Spezifikation parallel analysiert, erkennt es die Abweichungen. Diese Abweichungen zeigen sich in drei erkennbaren Mustern:
- Nicht dokumentierte Endpunkte. Sie sind im Code enthalten und wurden nie in die Spezifikation aufgenommen.
- Zombie-Endpunkte. Sie sind als veraltet oder außer Betrieb genommen gekennzeichnet und dennoch erreichbar.
- Verwaiste Endpunkte. Sie gehören keinem der aktuellen Teammitglieder.
Keines dieser Produkte taucht in einer reinen Spezifikationsliste auf, weil genau diese Produkte in der Spezifikation fehlen.
Beweise, auf die Sie reagieren können, keine Aufforderung zur Untersuchung.
Jeder Befund verweist auf den exakt verantwortlichen Handler: die Datei, die Klasse, die Methode und die spezifische Zeile, die den Fehler verursacht hat, zusammen mit dem fehlerhaften Code. Jeder Befund enthält außerdem seinen Schweregrad, seine Kategorie gemäß OWASP API Security Top 10, sein CWE (Critical Worker Error), den Authentifizierungsstatus des Endpunkts und die Sensibilitätsklassifizierung der betroffenen Daten.
Eine Fehlermeldung, die lediglich einen Endpunkt nennt, lässt Entwickler den gesamten Quellcode durchsuchen, bevor sie überhaupt mit der Fehlerbehebung beginnen können. Eine Fehlermeldung, die die Zeile nennt, führt sie hingegen direkt zur Fehlerbehebung.
Die Ergebnisse werden als JSON, CSV, Markdown und SARIF 2.1.0 exportiert und landen somit im Zielverzeichnis.Tools, mit denen Ihre Teams bereits arbeiten.
Der Handler, die Zeile und der Code, die die Sicherheitslücke verursacht haben. Kein Grund für eine Untersuchung.
Warum dies auf einer Plattform und nicht auf einer anderen Konsole verfügbar ist
Xygeni betreibt API-Sicherheit parallel SAST, SCA, Secrets Security, IaC und DAST innerhalb einer einzigen Plattform, korreliert durch ASPM, anstatt es als separates Tool mit eigener Software auszuliefern login und seinem eigenen Bearbeitungsrückstand.
Das ist wichtig, weil statische und Laufzeit-Ergebnisse unterschiedliche Fragen zum selben Endpunkt beantworten und gemeinsam nützlicher sind als getrennt. Statische Ergebnisse zeigen an, ob ein Endpunkt riskant ist, bevor er veröffentlicht wird. DAST bestätigt, was tatsächlich erreichbar und angreifbar ist, sobald der Endpunkt läuft.
Verteilt man das auf zwei Konsolen, entstehen aus korrelierten Risiken zwei unabhängige Backlogs. Niemand gleicht sie ab, und der Endpunkt, der weder dokumentiert noch authentifiziert ist, befindet sich in keiner der Warteschlangen.
Sehen Sie Ihre tatsächliche API-Angriffsfläche. API-Sicherheit ist verfügbar als Enterprise Als Add-on für die Xygeni-Plattform wird ein Scan Ihrer eigenen Repositories innerhalb Ihrer eigenen Infrastruktur durchgeführt.
FAQ
Kann es erkennen, welche Endpunkte sensible Daten verarbeiten?
Ja. Xygeni kennzeichnet PII, PCI und PHI in Endpunktparametern und -antworten und verwendet diese Klassifizierung, um die Ergebnisse nach der tatsächlichen Exposition zu ordnen.
Läuft es auf jedem pull request?
Ja. Die inkrementelle Scan-Methode analysiert nur die geänderten Endpunkte, und das erzeugte Manifest kann einen nachfolgenden DAST-Scan auf dieselben Endpunkte konzentrieren, sodass statische und Laufzeittests auf die tatsächlich vorgenommenen Änderungen abgestimmt bleiben.
Verlässt mein Code meine Umgebung?
Nein. Die Scans werden in Ihrer eigenen Infrastruktur durchgeführt. Nur die Ergebnisse werden hochgeladen und sowohl während der Übertragung als auch im Ruhezustand geschützt.
Wie erhalte ich API-Sicherheit?
API-Sicherheit ist verfügbar als Enterprise Zusatzoption. Fordern Sie einen Proof of Concept an, und der Umfang wird mit Ihnen abgestimmt.
