Using your API Specs to attack your APIs

The talk opens with recent data breaches traced to misconfigured APIs and argues that organisations often leave endpoints exposed without knowing it. The speaker explains why dynamic scanners struggle with APIs: websites expose links a crawler can follow, while APIs need an explicit map of their endpoints. Machine-readable definitions such as OpenAPI and Swagger files supply that map, and they differ from developer documentation written for integration.

Next, the speaker shows how an outsider might locate APIs through public API directories, partner portals, DNS lookups, mobile app decompilation and wordlists, and how a published spec then tells a tool where each route and method lives. Examples include a public GraphQL playground that returned a full database schema through introspection, and a telecom endpoint that disclosed customer details for a phone number. Techniques covered include removing authentication headers and probing low-numbered object IDs for broken object-level authorization, along with the infrastructure, rotating IP addresses and account creation that automated abuse requires.

The closing advice focuses on reducing attack surface: inventory every endpoint and retire old API versions, keep specs internal and behind access controls, disable default admin panels and playgrounds, and generate specs for new APIs so teams can compare live traffic against them. Monitoring outbound response sizes and request patterns can help catch bulk data extraction and enumeration early.