API - Enumeration: Difference between revisions

From PiRho Knowledgebase
Jump to navigationJump to search
Dex (talk | contribs)
No edit summary
Dex (talk | contribs)
mNo edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Category:API]]
[[Category:API]]
[[Category:HTTP]]
[[Category:HTTP]]
Hopefully, the API has a Swagger or WSDL document which describes the entire hierarchy, operations and data types. If not, Documentation is the next go-to. Good documentation should each API endpoint and how to interact with it. Failing that, a technique called Fuzzing (dictionary-based brute-force) may be used. It is also possible to perform a complete brute-force enumeration. Tools like DirBuster and Burp support both techniques.<br/>
When working with an unfamiliar or undocumented API, the first task is to discover its endpoints and then build a complete interaction profile for each one. This article explains reliable methods for endpoint discovery, documentation analysis, fuzzing, and creating structured API interaction profiles.
It is neccessary to create a profile of each endpoint, detailing Method, Authentication, Headers, Payload and Data Structures. Some endpoints can be read-only, which will produce output using GET, others can-be write-only, only responding correctly to the POST, PUT, DELETE and PATCH methods and possibly only producing a response code without a payload.<br/>
 
Using a tool like Postman it is possible to stage a collection of requests, for each endpoint, with different interactions. This collection can be output as a library of stored procedures in many programming languages.
== Understanding API Discovery ==
Before interacting with any API, you need to know what endpoints exist, what operations they support, and what data structures they expect or return.
 
Modern APIs often expose formal descriptions such as:
* '''Swagger / OpenAPI documents''' – Machine-readable specifications describing paths, parameters, schemas, and examples.
* '''WSDL''' – XML-based contracts defining operations, bindings, and message structures.
* '''WADL''' – Describes REST endpoints, resources, and supported HTTP methods.
 
If a formal schema is exposed, it becomes the authoritative map of the service.
 
== What If Documentation Is Missing? ==
If no schema is provided, the next step is to check:
* Developer documentation
* API reference sections
* Embedded metadata
* Inline code examples
 
Good documentation should outline:
* Available endpoints
* Required parameters
* Authentication model
* Expected headers
* Data formats
* Typical success/error responses
 
== Endpoint Discovery Techniques ==
When neither schema nor documentation is available, enumeration techniques become necessary.
 
=== Dictionary-Based Fuzzing ===
Fuzzing uses curated wordlists to probe the API for valid paths. Tools such as ''DirBuster'', ''Burp Suite'', and ''FFUF'' can identify:
* Existing endpoints
* Hidden or legacy functions
* Administrative or debug endpoints
* Versioned API structures
 
=== Full Brute-Force Enumeration ===
If subtle fuzzing fails, a full brute-force enumeration may uncover:
* Deeply nested routes
* Unusual naming conventions
* Deprecated or internal functions
 
== Creating an Endpoint Profile ==
For each endpoint, create a complete behavioural profile.
 
=== HTTP Method ===
* GET – Typically read-only
* POST – Create or trigger operations
* PUT/PATCH – Update
* DELETE – Remove
 
=== Authentication Requirements ===
Document:
* API keys
* OAuth tokens
* Cookies
* Custom headers
 
=== Required Headers ===
Examples:
* Content-Type
* Accept
* Authorization
* Vendor-specific headers
 
=== Payload Structure ===
Record:
* JSON/XML schema
* Multipart boundaries
* Required vs optional fields
* Allowed values
 
Some endpoints are write-only and may return only HTTP status codes.
 
=== Response Model ===
Document:
* Success responses
* Error codes
* Rate limits
* Pagination formats
 
== Using Postman for Analysis ==
Tools like Postman and Insomnia help build collections that:
* Store successful/failing examples
* Capture real payloads
* Document authentication
* Provide reusable request templates
 
Postman can export:
* cURL commands
* JavaScript fetch/axios
* Python Requests
* PHP, C#, Java, Go snippets
 
== When to Update an Endpoint Profile ==
Update when:
* API version changes
* Response formats shift
* New fields or behaviours appear
* Rate limits are introduced
* Deprecation warnings appear
 
== Related Articles ==
* [[HTTP Methods Explained]]
* [[Understanding RESTful API Design]]
* [[Working with JSON and XML Payloads]]
* [[Using Postman for API Testing]]
 
== References ==
* OpenAPI Specification
* WSDL Standards
* WADL Specification
* OWASP API Security Testing Guidance

Latest revision as of 13:20, 14 March 2026

When working with an unfamiliar or undocumented API, the first task is to discover its endpoints and then build a complete interaction profile for each one. This article explains reliable methods for endpoint discovery, documentation analysis, fuzzing, and creating structured API interaction profiles.

Understanding API Discovery

Before interacting with any API, you need to know what endpoints exist, what operations they support, and what data structures they expect or return.

Modern APIs often expose formal descriptions such as:

  • Swagger / OpenAPI documents – Machine-readable specifications describing paths, parameters, schemas, and examples.
  • WSDL – XML-based contracts defining operations, bindings, and message structures.
  • WADL – Describes REST endpoints, resources, and supported HTTP methods.

If a formal schema is exposed, it becomes the authoritative map of the service.

What If Documentation Is Missing?

If no schema is provided, the next step is to check:

  • Developer documentation
  • API reference sections
  • Embedded metadata
  • Inline code examples

Good documentation should outline:

  • Available endpoints
  • Required parameters
  • Authentication model
  • Expected headers
  • Data formats
  • Typical success/error responses

Endpoint Discovery Techniques

When neither schema nor documentation is available, enumeration techniques become necessary.

Dictionary-Based Fuzzing

Fuzzing uses curated wordlists to probe the API for valid paths. Tools such as DirBuster, Burp Suite, and FFUF can identify:

  • Existing endpoints
  • Hidden or legacy functions
  • Administrative or debug endpoints
  • Versioned API structures

Full Brute-Force Enumeration

If subtle fuzzing fails, a full brute-force enumeration may uncover:

  • Deeply nested routes
  • Unusual naming conventions
  • Deprecated or internal functions

Creating an Endpoint Profile

For each endpoint, create a complete behavioural profile.

HTTP Method

  • GET – Typically read-only
  • POST – Create or trigger operations
  • PUT/PATCH – Update
  • DELETE – Remove

Authentication Requirements

Document:

  • API keys
  • OAuth tokens
  • Cookies
  • Custom headers

Required Headers

Examples:

  • Content-Type
  • Accept
  • Authorization
  • Vendor-specific headers

Payload Structure

Record:

  • JSON/XML schema
  • Multipart boundaries
  • Required vs optional fields
  • Allowed values

Some endpoints are write-only and may return only HTTP status codes.

Response Model

Document:

  • Success responses
  • Error codes
  • Rate limits
  • Pagination formats

Using Postman for Analysis

Tools like Postman and Insomnia help build collections that:

  • Store successful/failing examples
  • Capture real payloads
  • Document authentication
  • Provide reusable request templates

Postman can export:

  • cURL commands
  • JavaScript fetch/axios
  • Python Requests
  • PHP, C#, Java, Go snippets

When to Update an Endpoint Profile

Update when:

  • API version changes
  • Response formats shift
  • New fields or behaviours appear
  • Rate limits are introduced
  • Deprecation warnings appear

Related Articles

References

  • OpenAPI Specification
  • WSDL Standards
  • WADL Specification
  • OWASP API Security Testing Guidance