API’s (Application Programming Interfaces) are back-end services which expose an interface which can be used to connect to and transact or read/write information to and from a back-end system. They are extremely useful and a great architecture decision delivering flexibility and extensiblity of a service.
APIs deliver functionality once the client service knows how to talk to the API. APIs generally sit behind a HTTP port and can’t be seen unlike a website but they may deliver an equal level of value and functionality to the requesting client.
Many websites may use an API but the user does not invoke the API directly but rather the Website /App is a proxy for the API. APIs are not built to be human readable, like a website, but rather machine readable.
You may have APIs hosted on systems behind HTTP ports but are undiscovered. They may be well known but they may also be old or development deployments which are forgotten about. We can’t secure what we don’t know about.
Adequate assessment involves coverage of entire corporate ranges (CIDR ranges), large lists of IPs, domain names (FQDN’s) and using a multi-layer probing methodology detailed below:
API discovery is a combination of both host layer and web layer investigation. Some are easier to discover than others.
Discovering API artifacts:
Discovery of APIs may require multiple layers of probing. If we don’t know how to invoke a given API, identification across many levels is required to accurately provide a confidence interval if an API is present or not.
Assessment of APIs can be difficult as the assessment methodology requires knowledge of how to communicate and invoke the API.
Running a simple web scanner against an API simply does not work. A scanner would just hit an initial URL and not know how to invoke or traverse the various API calls.
Good API assessment should have the ability to read/ingest descriptor files in order to understand how to communicate and invoke the API. Once this is done a scanner can assess the API method calls.
As the development team alter and change the API, the assessment technology can read the newly updated descriptor file and assess the API including new changes.
Keeping pace with change.
Assessment of vulnerabilities specific to API’s is also important.
Items discussed in the OWASP API Top 10 are an important aspect to true API specific testing.
DevOps: In a DevOps environment the descriptor file can be used to determine change/deltas since the last deployment of the API and only assess the changes saving valuable time in a fast DevOps environment – Iterative testing when frequent change occurs.
Marketing Executive of Edgescan