API Recon
Introduction
In order to target APIs, you must first be able to find them. In this module, we will learn how to uncover the API attack surface of a target using passive and active reconnaissance techniques.
How an API is meant to be consumed will determine how easily it can be found. Public APIs are meant to be easily found and used by end-users. Public APIs may be entirely public without authentication or be meant for use by authenticated users. Authentication for a public API primarily depends on the sensitivity of the data that is handled. If a public API only handles public information then there is no need for authentication, in most other instances authentication will be required. Public APIs are meant to be consumed by end-users. In order to facilitate this, API providers share documentation that serves as an instruction manual for a given API. This documentation should be end-user friendly and relatively straightforward to find.
Partner APIs are intended to be used exclusively by partners of the provider. These might be harder to find if you are not a partner. Partner APIs may be documented, but documentation is often limited to the partner.
Private APIs are intended for use, privately, within an organization. These APIs are often documented less than partner APIS, if at all, and if any documentation exists it is even harder to find.
In all instances where API documentation is unavailable, you will need to know how to reverse engineer API requests. We will cover reverse engineering in a follow-up module. For now, we will focus on detecting APIs and using them as described within discovered documentation.
Web API Indicators
APIs meant for consumer use are meant to be easily discovered. Typically, the API provider will market their API to developers who want to be consumers. So, it will often be very easy to find APIs, just by using a web application as an end-user. The goal here is to find APIs to attack and this can be accomplished by discovering the API itself or the API documentation. If you can find the target's API and documentation as an end-user then mission accomplished, you have successfully discovered an API.
Another way to find an API provided by a target is to look around the target's landing page. Look through a landing page for links to API or development portal. When searching for APIs there are several signs that will indicate that you have discovered the existence of a web API. Be on the lookout for obvious URL naming schemes:
https://target-name.com/api/v1
https://api.target-name.com/v1
https://dev.target-name.com/rest
Look for API indicators within directory names like: /api, /api/v1, /v1, /v2, /v3, /rest, /swagger, /swagger.json, /doc, /docs, /graphql, /graphiql, /altair, /playground
Also, subdomains can also be indicators of web APIs:
api.target-name.com
uat.target-name.com
dev.target-name.com
developer.target-name.com
test.target-name.com
Another indicator of web APIs is the HTTP request and response headers. The use of JSON or XML can be a good indicator that you have discovered an API.
HTTP Request and Response Headers containing "Content-Type: application/json, application/xml"
Also, watch for HTTP Responses that include statements like: {"message": "Missing Authorization token"}
One of the most obvious indicators of an API would be through information gathered using third-Party Sources like Github and API directories.
Gitub: https://github.com/
Postman Explore: https://www.postman.com/explore/apis
ProgrammableWeb API Directory: https://www.programmableweb.com/apis/directory
APIs Guru: https://apis.guru/
Public APIs Github Project: https://github.com/public-apis/public-apis
RapidAPI Hub: https://rapidapi.com/search/
When searching for a target's APIs use a target's web application as it was designed. Use a browser go to the web application and see if an API is advertised. Once you have an idea of how the web app functions, dig deeper by deploying passive and active reconnaissance techniques.
Last updated