42Crunch ordnet jedes Risiko des OWASP API Security Top 10 (2023) einer konkreten Kontrolle im Zyklus Contract → Audit → Scan → Protect zu, sodass Lücken vor dem Go-Live entdeckt werden — nicht erst nach einem Sicherheitsvorfall.
Die API-Sicherheitsplattform von 42Crunch ist ein Satz automatisierter Tools, die APIs vom Design bis zur Produktion absichern: API Audit prüft den OpenAPI-Contract bereits beim Design, API Scan testet die laufende Implementierung dynamisch während der Entwicklung und in CI/CD, und API Protection setzt den freigegebenen Contract als Laufzeit-Mikro-Firewall durch. Zusammen bieten sie durchgehende Abdeckung gegen jede Kategorie des OWASP API Security Top 10 — kein einmaliges Audit, das schon am Tag danach veraltet ist.
Ein Endpunkt legt einen Objekt-Identifikator offen — eine Benutzer-ID, eine Bestell-ID, eine Datensatz-ID — und prüft nicht, ob der Aufrufer tatsächlich die Berechtigung hat, auf genau dieses Objekt zuzugreifen. Ändert man die ID in der Anfrage, blickt man auf die Daten einer anderen Person.
Objektbezogene Autorisierung wird automatisch in API Scan getestet, mit CI/CD-Gates, die verwundbare APIs blockieren, bevor sie in Produktion gehen.
Schwachstellen in der Art, wie eine API prüft, wer sie aufruft — fehlende Rate-Limits beim Login, zu lasche Passwortregeln, unsichere Token-Ausgabe oder -Validierung, Zugangsdaten, die in Logs landen — ermöglichen es einem Angreifer, sich als legitimer Nutzer auszugeben oder die Authentifizierung ganz zu umgehen.
OpenAPI-Contracts werden bei schwachen oder fehlenden Auth-Schemata markiert; dynamische Scans testen mit ungültigen Tokens und Zugangsdaten; die JWT-Validierung zur Laufzeit erfolgt gemäß RFC 8725.
Selbst wenn der Zugriff auf ein Objekt selbst korrekt geprüft wird, sind einzelne Eigenschaften darin möglicherweise nicht abgesichert — sodass ein Nutzer Felder lesen kann, die er nicht sehen sollte, oder in Felder (etwa eine Rolle oder einen Kontostand) schreiben kann, die er niemals ändern dürfen sollte.
Sichere Request-/Response-Schemata werden bereits beim Design durchgesetzt, laufend auf Abweichungen erneut geprüft, mit Blockierung zur Laufzeit von allem, was der Contract nicht deklariert.
Eine API, die nicht begrenzt, wie viel ein Client anfordern kann — Antwortgröße, Datensatzanzahl, Ausführungszeit, gleichzeitige Vorgänge — kann in die Höhe getrieben oder regelrecht überlastet werden, sei es durch einen gezielten Angriff oder schlicht unkontrollierte Nutzung.
Rate-Limits und Payload-Beschränkungen werden im OpenAPI-Contract definiert und zur Laufzeit durchgesetzt, mit JSON-Parser-Schutz gegen überdimensionierte oder zu komplexe Payloads.
Komplexe Rollen- und Berechtigungshierarchien machen es leicht, eine administrative oder privilegierte Operation für Nutzer erreichbar zu lassen, die nur Standardzugriff haben sollten — eine Autorisierungslücke auf Ebene der Funktion selbst, nicht der Daten, die sie berührt.
Die Laufzeit erlaubt nur die Ausführung von im Contract definierten Operationen — undefinierte Operationen und unbekannte Endpunkte werden standardmäßig blockiert.
Jede technische Kontrolle kann korrekt durchgesetzt sein, und ein Geschäftsprozess — der Kauf von Artikeln mit begrenztem Bestand, das Posten von Bewertungen, das Eröffnen von Konten — kann trotzdem missbraucht werden, wenn nichts einschränkt, wie oft er aufgerufen wird, sodass Automatisierung ihn in einer Geschwindigkeit oder einem Umfang ausnutzen kann, den kein echter Nutzer erreichen könnte.
Chaotische Testfälle für Geschäftsabläufe laufen während Audit und Scan, wodurch das Rauschen reduziert wird, sodass Tools zur Verhaltensüberwachung Missbrauchsmuster schneller erkennen können.
Eine API, die eine entfernte Ressource über eine vom Client übergebene URL abruft — ohne zu prüfen, wohin diese URL tatsächlich zeigt — kann dazu gebracht werden, im Auftrag des Angreifers Anfragen an interne Infrastruktur oder nicht vorgesehene externe Dienste zu senden.
Szenariotests validieren das Verhalten vor der Produktion; zur Laufzeit werden alle vom Client gelieferten Eingaben bereinigt und validiert.
Kleine Lücken summieren sich: unnötig aktiviert gelassene Funktionen, fehlende Sicherheits-Header, zu ausführliche Fehlermeldungen, zu großzügiges CORS, veraltete Komponenten. Einzeln geringfügig, vergrößern sie zusammengenommen die Angriffsfläche erheblich.
Sicherheit wird von Anfang an in den Contract eingebaut — Transport, Header, Verben und Content-Types werden durchgesetzt und laufend zur Laufzeit validiert.
APIs vermehren sich schneller, als die Dokumentation mithalten kann — alte Versionen, Staging-Endpunkte und undokumentierte Integrationen bleiben lange erreichbar, nachdem niemand mehr aktiv den Überblick behält, jede einzelne eine reale Angriffsfläche außerhalb des Inventars des Teams.
Kontinuierliche Discovery findet undokumentierte APIs in Code-Repositories und zur Laufzeit; undokumentierte und ausgemusterte APIs werden standardmäßig blockiert.
Entwickler neigen dazu, Daten von Drittanbieter- und Partner-APIs mehr zu vertrauen als Nutzereingaben — mit schwächerer Validierung und dem bedenkenlosen Folgen von Weiterleitungen — wodurch ein Fehler in einem Dienst, den man nicht kontrolliert, zu einem Fehler im eigenen Dienst wird.
Derselbe contract-gesteuerte Standard gilt auch für Drittanbieter-APIs, die Ihr Dienst konsumiert — nicht nur für die, die Sie selbst veröffentlichen.
Deckt auch die Ausgabe OWASP API Security Top 10: 2019 ab, auf dieselbe Weise zugeordnet.
Statische Analyse des OpenAPI-Contracts beim Design — über 300 automatisierte Prüfungen, sofort bewertet in Ihrer IDE.
Dynamische Tests gegen die laufende API mit simuliertem echtem Traffic, direkt zugeordnet zum OWASP API Top 10.
Der freigegebene Contract wird zur Laufzeit-Durchsetzungsrichtlinie — ein positives Sicherheitsmodell, keine Blockliste.
Eine von der Community gepflegte Liste der zehn kritischsten API-Sicherheitsrisiken, veröffentlicht von OWASP — dieselbe Standardreferenz, die die breitere AppSec-Branche zur Priorisierung von API-Schwachstellen nutzt. 42Crunch verfolgt sowohl die Ausgabe 2023 als auch 2019.
Jede Kategorie ist einer konkreten Kontrolle in Audit, Scan und Protection zugeordnet — manche werden bereits beim Design im Contract erkannt, manche dynamisch beim Testen, und manche laufend zur Laufzeit durchgesetzt. Keine einzelne Stufe deckt für sich allein jede Kategorie ab; erst alle drei zusammen tun das.
Nein — es ergänzt eines. Eine generische WAF oder ein Gateway prüft Traffic gegen generische Regelwerke; der Laufzeitschutz von 42Crunch setzt Ihren spezifischen OpenAPI-Contract als positives Sicherheitsmodell durch und erkennt so, was ein generisches Regelwerk nie spezifisch genug erkennen kann.
Automatisch. Die Abdeckung wird direkt aus Ihrem OpenAPI-Contract generiert — es gibt kein separates Regelwerk, das von Hand geschrieben oder gepflegt werden müsste.
Ja. Befunde werden beiden Ausgaben zugeordnet, sodass Teams, die noch gegen die Liste von 2019 berichten, und Teams, die zu 2023 gewechselt sind, gleichermaßen eine präzise, aktuelle Abdeckung erhalten.
Richten Sie 42Crunch auf Ihren OpenAPI-Contract und sehen Sie genau, wo Sie bei allen zehn Kategorien stehen — keine Agent-Installation, keine Verpflichtung erforderlich.