Die Flexibilität von GraphQL ist genau das, was herkömmliche, auf REST ausgerichtete Tools übersehen. 42Crunch wendet auf GraphQL-Schemas dasselbe contract-first-Sicherheitsmodell an, das bereits für OpenAPI gilt — statische Analyse, Live-Tests und automatisierte Durchsetzung.
Ein einzelner flexibler Endpunkt, clientseitig geformte Queries und verschachtelte Resolver verleihen GraphQL echte Stärke — und eine eigene Klasse von Schwachstellen, nach denen Tools, die auf REST-Routen und HTTP-Verben ausgelegt sind, schlicht nicht suchen. Schema-Exposition, Ressourcenerschöpfungsangriffe durch tief verschachtelte oder teure Queries, unautorisierter Datenzugriff über unzureichend geschützte Felder, ungeschützte Mutationen und Lücken an den Rändern föderierter Dienste liegen alle außerhalb dessen, wonach ein herkömmlicher Scanner sucht.
Bleibt die Introspection aktiviert, erhält ein Angreifer Ihren gesamten Datengraphen als Karte — einschließlich Feldern und Mutationen, die niemand veröffentlichen wollte.
Tief verschachtelte oder kostenintensive Queries können eine einzelne Anfrage in einen Denial-of-Service verwandeln — GraphQL erlaubt einem Client, eine Query so zu formen, wie REST es nie zuließ.
Eine Autorisierungslücke auf Feldebene taucht in keiner Routenliste auf — sie zeigt sich erst, wenn das falsche Feld Daten zurückgibt, die es nicht sollte.
Mutationen bergen dasselbe Schreibrisiko wie ein REST-POST oder -PUT, werden bei der Schemaprüfung aber selten ebenso genau untersucht.
Ein Supergraph ist nur so sicher wie sein am wenigsten geprüfter Subgraph — Föderation vervielfacht die Angriffsfläche, ohne die Prüfung entsprechend zu vervielfachen.
42Crunch bewertet das GraphQL-SDL selbst — Introspection- und Datenexpositionsrisiko, fehlende Authentifizierung bei Queries und Mutationen, unbeschränkte Strings und benutzerdefinierte Skalare, fehlende Eingabevalidierung, Abdeckung von Query-Kosten und Listengröße sowie die Sicherheit von Apollo-Federation-Subgraphen. Jeder Befund wird bewertet und zugeordnet, genau wie bei einem OpenAPI-Contract-Audit, noch bevor eine einzige Anfrage einen laufenden Server erreicht.
Contractbewusste dynamische Tests prüfen Authentifizierungs- und Autorisierungsschwächen, Missbrauch verschachtelter Operationen und Query-Komplexität, Sicherheitsmängel bei Mutationen, ungültige und böswillige Feldeingaben sowie Sicherheitsprobleme bei Föderation und Subgraphen — und validieren, dass sich der Live-Dienst so verhält, wie das Schema es behauptet, nicht nur, dass sich das Schema gut liest.
Ein dediziertes GraphQL Security Quality Gate vergleicht Audit- und Scan-Ergebnisse mit einem genehmigten Schwellenwert und lässt den Build fehlschlagen oder blockiert die Freigabe, wenn ein Schema oder eine laufende API diesen nicht erreicht — dasselbe Durchsetzungsmodell, das 42Crunch bereits auf REST anwendet, erweitert bis auf die Query-Ebene. Sobald ein Contract validiert ist, steuert genau diese Definition die präzise Laufzeit-Durchsetzung, solange die API live ist.
Nicht allein. Eine WAF arbeitet auf HTTP- und Netzwerkebene, ohne Einblick in GraphQL-Spezifika — Schemastruktur, Resolver-Beziehungen, Zugriff auf Feldebene oder die Zusammensetzung eines föderierten Graphen. Um zu erkennen, was in GraphQL tatsächlich schiefgeht, braucht es schemabewusste Analyse und Tests, nicht nur Traffic-Inspektion.
Nein. Der statische SDL-Audit liest die Schemadefinition direkt, ohne jemals einen Live-Endpunkt aufzurufen. Nur der dynamische Scan verbindet sich mit einer laufenden API — typischerweise Staging, nicht Produktion —, sodass die Introspection dort deaktiviert bleiben kann, wo es am wichtigsten ist.
Ja — die Abdeckung von Query-Kosten und Listengröße ist Teil des statischen Audits, und der dynamische Scan testet gezielt den Missbrauch verschachtelter Operationen und Query-Komplexität gegen die laufende API, sodass eine teure Query erkannt wird, bevor sie zu einem Denial-of-Service wird.
Ja, einschließlich der Bewertung von Subgraph und Supergraph. Da ein zusammengesetzter Graph die eigenen Zugriffskontrollen eines Subgraphen verbergen kann, rekonstruiert 42Crunch die Zuständigkeit und den Validierungskontext der Subgraphen, statt den Graphen nur im zusammengesetzten Zustand zu beurteilen.
Ja — beide werden innerhalb derselben Plattform organisiert, auditiert, getestet und governiert, sodass ein gemischtes REST-und-GraphQL-Portfolio unter einer einzigen, konsistenten Sicherheitsrichtlinie läuft statt unter zwei getrennten Tools.
Über dedizierte GraphQL Security Quality Gates. Audit- und Scan-Ergebnisse werden mit einem genehmigten Schwellenwert verglichen, und ein Build oder eine Freigabe kann automatisch fehlschlagen, wenn ein Schema oder eine laufende API diesen nicht erreicht.
Ja — jeder Befund verlinkt auf einen GraphQL-spezifischen Eintrag in der Knowledge Database, mit der betreffenden Stelle im SDL, einer Erklärung des Risikos, einem realistischen Angriffsszenario und der empfohlenen Korrektur.
Ja — Validierungsdirektiven, die mit Spring GraphQL und graphql-java verwendet werden, einschließlich @Min, @Max, @Size, @Pattern und @NotEmpty, werden erkannt statt als undurchsichtige Schema-Dekoration behandelt.
Nein. Es handelt sich um einen vollständigen Lebenszyklus: statischer SDL-Audit, dynamischer Scan gegen die laufende API, CI/CD Security Quality Gates und contractgesteuerter Laufzeitschutz, sobald die API live ist.
Richten Sie 42Crunch auf ein GraphQL-Schema oder einen Live-Endpunkt, und erhalten Sie einen bewerteten Audit zurück — keine Agenten-Installation, keine Verpflichtung erforderlich.