API Endpoint Enumeration

API endpoint enumeration is the process of systematically discovering and cataloging the available endpoints (URLs) of an API. This includes both documented and undocumented endpoints, as well as understanding the methods (GET, POST, PUT, DELETE) and parameters each endpoint accepts. For a penetration tester, this is a foundational step to identify attack surface, misconfigurations, and vulnerabilities such as broken access control, excessive data exposure, or injection flaws.

Modern applications rely heavily on APIs, often exposing dozens or hundreds of endpoints. Developers may leave debug endpoints, deprecated versions, or hidden administrative functions accessible. Attackers can exploit these to gain unauthorized access or leak sensitive data. Enumeration helps testers map the entire API surface, including endpoints not intended for public consumption.

The process typically involves several techniques:

Using curl to enumerate endpoints:

curl -X GET https://api.example.com/v1/users -H "Authorization: Bearer token123"

To test different methods:

curl -X OPTIONS https://api.example.com/v1/users -v

To brute-force endpoints with a wordlist:

for endpoint in $(cat endpoints.txt); do
  code=$(curl -s -o /dev/null -w "%{http_code}" https://api.example.com/v1/$endpoint)
  echo "$endpoint -> $code"
done

To fuzz parameters:

curl -X GET "https://api.example.com/v1/users?id=1"
curl -X GET "https://api.example.com/v1/users?page=1&limit=10"

API endpoint enumeration often overlaps with:

1. Documentation Discovery

Many APIs provide OpenAPI/Swagger documentation. Common paths include: - /swagger.json - /swagger/v1/swagger.json - /api/docs - /v1/api-docs - /openapi.json

If found, the documentation lists all endpoints, parameters, and authentication requirements. This is the most efficient enumeration method.

2. Web Crawling and Spidering

Use tools like Burp Suite's Spider or ZAP's AJAX Spider to crawl the application. JavaScript files often contain API endpoint URLs. For example, in a React app, API calls may be in minified JS files. Look for strings like "api/", "/v1/", or "endpoint".

3. Brute-Forcing with Wordlists

Use wordlists tailored for APIs, such as SecLists's /Discovery/Web-Content/api-endpoints.txt. Example command:

ffuf -u https://api.example.com/v1/FUZZ -w api-endpoints.txt -mc 200,201,403

Filter for status codes that indicate existence (200, 201, 403) versus non-existence (404).

4. HTTP Method Testing

For each discovered endpoint, test all methods:

curl -X GET https://api.example.com/v1/users
curl -X POST https://api.example.com/v1/users
curl -X PUT https://api.example.com/v1/users/1
curl -X DELETE https://api.example.com/v1/users/1
curl -X PATCH https://api.example.com/v1/users/1

Observe responses: A 405 Method Not Allowed indicates the method is recognized but not allowed; a 200 or 201 indicates it's functional.

5. Parameter Fuzzing

Add common parameters to endpoints to discover hidden functionality. For example:

curl -X GET "https://api.example.com/v1/users?admin=true"
curl -X GET "https://api.example.com/v1/users?debug=1"
curl -X GET "https://api.example.com/v1/users?format=json"

6. Error-Based Enumeration

Send requests with invalid input to trigger error messages that reveal endpoint paths. For example:

curl -X POST https://api.example.com/v1/users -d "invalid"

If the server returns a stack trace, it may show internal paths like "/var/www/api/v1/controllers/userController.php".

7. GraphQL Introspection

If the API uses GraphQL, query the introspection system:

query {
  __schema {
    types {
      name
      fields {
        name
        type {
          name
        }
      }
    }
  }
}

This returns all types and fields, effectively listing all possible queries and mutations.

API endpoint enumeration is a systematic process combining documentation review, crawling, brute-forcing, and parameter fuzzing. It reveals the full attack surface of an API, enabling testers to find vulnerabilities like broken access control, information disclosure, and injection flaws. On the PT0-002 exam, expect scenario-based questions where you must choose the correct enumeration technique or interpret API responses.

A large e-commerce company uses a RESTful API for its mobile app and web store. The API has endpoints for products, users, orders, and payments. During a penetration test, the tester discovers that the API documentation is exposed at /swagger.json without authentication. This reveals endpoints like /api/v1/admin/users and /api/v1/admin/orders. By brute-forcing, the tester finds that /api/v1/admin/users returns a list of all users (including PII) when accessed with a regular user token, indicating a broken access control vulnerability. The misconfiguration allowed any authenticated user to access admin endpoints. The fix required implementing role-based access control (RBAC) on the server side.

A bank provides an API for third-party developers to integrate payment services. The API uses OAuth2 with scopes. The tester enumerates endpoints by reviewing the developer portal's JavaScript and discovers a hidden endpoint /api/v1/internal/transactions that is not documented. This endpoint returns transaction data without requiring the proper scope. The bank had intended this endpoint for internal use only but forgot to restrict access. The vulnerability could have allowed attackers to view other customers' transactions. The remediation involved removing the endpoint or adding proper scope validation.

A SaaS company offers a GraphQL API. The tester uses introspection to query the schema and discovers a mutation called 'deleteUser' that is not exposed in the frontend. By sending a mutation with a user ID, the tester can delete any user account. The introspection endpoint was not disabled in production. The company disabled introspection in production and implemented query depth limiting. This scenario highlights the importance of disabling introspection in production environments and using allowlists for mutations.