API testing with AI: OpenAPI and GraphQL

Modern apps are a thin front end over an API, and the API is often where the real bugs are. The good news for a tester is that APIs tend to describe themselves: REST APIs ship OpenAPI specifications, and GraphQL APIs answer introspection queries. Both give you a map the model can read. This post follows testing common web bugs and leads into building a hackbot.

#APIs break differently

The OWASP API Security Top 10 puts authorization at the top. The two to learn first are broken object level authorization, where you reach another user's object, and broken function level authorization, where you call an admin action as a normal user. Both are the API version of the access-control bugs from the last post, and both are common because the API has many endpoints and one of them usually forgets the check.

#Find the OpenAPI spec

Many APIs publish their own specification. Common locations are /openapi.json, /swagger.json, /v1/openapi.json, or a docs page that loads one. Fetch it and you have every path, method, parameter, and schema in one file.

curl -s https://api.example.com/openapi.json -o openapi.json

Give the spec to the model and ask it to list the endpoints, mark the ones that read or write user-owned objects, and flag the ones whose names suggest an admin or internal role. That reading pass turns a long OpenAPI document into a ranked list of what to test first.

#GraphQL introspection

A GraphQL API usually answers an introspection query that returns its whole schema: every type, field, query, and mutation. When introspection is on, you get the full attack surface in one request.

curl -s https://api.example.com/graphql -H 'Content-Type: application/json' \
  -d '{"query":"{ __schema { queryType { name } mutationType { name } types { name kind } } }"}'

Hand the schema to the model and ask it to group the queries and mutations, pick out the ones that touch other users' data, and name the arguments each takes. The GraphQL specification describes introspection, and the OWASP Web Security Testing Guide has a section on testing GraphQL.

#Let the model plan, then test by hand

From either map, ask the model for a short test plan: for each object-owning endpoint, which two accounts to use and which id to swap; for each privileged operation, which low-privilege session to try it from. The model is good at turning a schema into this checklist. It cannot tell you whether the check is actually missing, so you run each case through your proxy with the accounts you control and read the result. A mutation that lets a normal user change another user's record is a clean BOLA, proven with two sessions.

#Verify and keep evidence

API findings are easy to prove and easy to overstate. Prove them with accounts you control, one variable at a time, and save the full request and response for each. For a BOLA, the evidence is two requests: your own object, then the other account's object returned to your session. For a BFLA, it is the privileged call succeeding from a session that should not be allowed to make it. Keep internal data you reach to the minimum needed to show impact, and describe only what you demonstrated.

#A note on automation and rate

APIs make it tempting to script hundreds of requests. Check the program's rules on automation and rate first, keep volume low on the live target, and do heavy iteration against a local copy. An API you hammer is an API whose owner notices for the wrong reason.

#Next in this track

You have now run the whole loop by hand. The next three posts build a small agent that runs the recon and testing steps for you, under your approval. Start with the hackbot architecture.