API - Enumeration: Difference between revisions
Created page with "Hopefully, the API has a 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..." |
No edit summary |
||
| Line 1: | Line 1: | ||
[[Category:API]] | |||
[[Category:HTTP]] | |||
Hopefully, the API has a 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 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.<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. | ||
Revision as of 12:01, 19 March 2025
Hopefully, the API has a 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.
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.
