MetaGraph

How MetaGraph works

MetaGraph is Escape’s traversal model for turning an API schema into a connected graph of resources and resolvers. That structure matters because the scanner can follow relationships instead of treating endpoints as isolated URLs, which helps it reason about how requests chain together and where valid paths actually exist.

In practice, this makes MetaGraph more than a schema parser. It becomes an execution map for the scan, letting the tool prioritise request sequences that are consistent with the API’s own logic rather than spending equal effort on every discovered route.

Why graph-based API analysis matters

API testing often fails when it relies on flat endpoint enumeration alone. Many business logic flaws only emerge after one operation creates state for another, or when a resolver exposes a resource relationship that is not obvious from the endpoint name. A graph representation helps surface those dependencies so the scanner can explore the application the way a real client or attacker would.

This is especially important for APIs built around nested resources, object relationships, and resolver-driven backends. The graph gives the scanner a way to model those dependencies explicitly, rather than inferring them from path strings or single-request responses.

What MetaGraph helps uncover

MetaGraph is useful where the security question is not “does this endpoint exist?” but “what can be reached, in what order, and with what data flow?” That makes it well suited to finding business logic flaws, broken request sequencing, and other weaknesses that depend on valid transitions between resources.

By prioritising plausible request chains, the scanner can reach states that simple discovery misses. That can expose authorisation gaps, unintended object access, or workflow flaws where the weakness only appears after the right sequence of actions has been established.

How to think about MetaGraph in assessment workflows

Practitioners should treat MetaGraph as a way to improve coverage, not as a guarantee of correctness. A graph can only be as accurate as the schema and resolver relationships it reflects, so incomplete schema input can reduce visibility into real application behaviour.

For that reason, graph-driven scanning works best alongside manual review of workflow assumptions, object relationships, and state-changing operations. The value is in making the scanner more context-aware, not in replacing deeper validation of the API’s business rules.

Risk and Threat Considerations

Graph-based API analysis highlights a real security risk: many of the most damaging API flaws are not visible from a single request or a simple endpoint list. If an attacker can follow valid resource chains, they may reach workflows, object relationships, or privileged operations that basic discovery never exercises.

Failure mechanism: A scanner or defender that only inventories endpoints can miss stateful paths, resolver relationships, and request order dependencies, leaving business logic flaws and access-control failures undetected until they are abused.

Impact: Missed paths can lead to unauthorized object access, workflow abuse, privilege expansion within the application, or other logic-driven compromise that is hard to spot with conventional perimeter-style testing.

Practitioner Guidance

Why practitioners should care: MetaGraph is most valuable when the API’s behaviour depends on relationships, not just routes. Use it to improve assessment quality for systems where sequence, object linkage, or resolver logic determines what a client can actually do.

What to watch for: If schema coverage is stale or incomplete, the graph can underrepresent the real attack surface. Treat the resulting scan as a strong starting point for prioritisation, then validate the high-value paths manually.