API testing: discovery and abuse

Notes on finding and abusing REST APIs during web testing — discovery when there's no documentation, then probing auth and object access. Short and practical; expands as I add GraphQL and JWT material.

#Discovering endpoints

APIs rarely sit at the web root and usually version their paths, so fuzz with a version pattern rather than a flat wordlist:

# pattern file feeds a version segment into each guess
cat pattern
{GOBUSTER}/v1
{GOBUSTER}/v2

gobuster dir -u http://<ip>:8080 -w /usr/share/wordlists/dirb/big.txt -p pattern

#Interacting with the API

Hit an endpoint, watch the response shape, then feed it what it expects:

# enumerate a resource collection
curl -i http://<ip>:5002/users/v1

# many APIs only parse JSON — set the content type and send a JSON body
curl -d '{"username":"admin","password":"fake"}' \
     -H 'Content-Type: application/json' \
     http://<ip>:5002/users/v1/login

From here the usual API bug classes apply: BOLA/IDOR (swap an object id and see if the server checks ownership), broken function-level auth (call admin-only routes as a low-priv user), mass assignment (add fields like "admin":true to a body the server blindly binds), and excessive data exposure (a /users list that returns password hashes or tokens). Enumerate every version — /v1 is often left unpatched after /v2 ships.