API - Enumeration: Difference between revisions
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
[[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/> | 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/> | ||
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/> | 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. This information could be available where there is a WADL file associated with an endpoint.<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. | 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. | ||
Latest revision as of 12:09, 19 March 2025
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.
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. This information could be available where there is a WADL file associated with an endpoint.
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.
