Hunting for Attack Paths in OpenAPI Documentations

The speaker, a penetration tester, starts from a practical gap: OpenAPI files describe every endpoint, parameter and data object an API exposes, and they are published in large numbers. Reviewing them by hand is slow, so the research asks whether the specification alone can reveal security design faults before an API is built or tested.

The approach loads the document into a Neo4j graph, with endpoints, methods, objects, fields and security requirements as nodes, then runs queries to find paths between them. Four attack-path ideas are covered: sensitive data reachable through both protected and public endpoints, identifiers that leak in other responses and can be reused, parallel endpoints that could spread data extraction past a per-endpoint rate limit, and fields that are reflected back to users. Nested object references and many optional elements made parsing messy.

Runs against a large corpus of public specifications surfaced a contact-details object that was open on one endpoint and authenticated on another, likely an oversight, and helped locate valid parameter values that would otherwise be guesswork. The closing takeaway is that graph queries can flag likely design mistakes early, which is useful to both defenders and testers, though findings still need manual verification and the prototype is rough.