Overview of the API Structure product and the new Open API specification comparison functionality
Hi all!
Today I will talk about our new product “API Structure” and the current changes in it. This product solves one of the most important tasks in API management – obtaining an up-to-date and complete API structure based on real traffic. The result is presented in the usual swagger form. Figure 1 shows a general view of the user interface.
The API structure is built based on the statistics of requests for endpoints. Infrequent or single requests are detected as noise and are not taken into account in the API design. Thanks to the constructed structure, it is possible:
define public and internal APIs;
understand through which APIs sensitive information, such as personal data, is transmitted;
filter endpoints under attack;
track changes in the API structure over a selected period of time;
get a complete list of malicious requests aimed at a specific endpoint;
download the constructed structure in OpenAPI v3 format;
configure firewall rules in another product in the Webmonitorex line.
More information about the API Structure product and its capabilities can be found in our documentation.
We are constantly developing our product in order to make it even more convenient and useful for our customers, as part of this process, the ability to compare OpenAPI Specifications (OAS) has been added to the “API Structure”. It allows you to load a new specification and compare it with an existing one. Thanks to this, it becomes possible to identify among the available APIs:
shadow APIs;
unused (orphan) APIs;
ghost (zombie) API.
What are ghost, unused, and shadow APIs? First things first. Let's start with the shadow APIs.
Shadow API – This is a hidden, undocumented API that was not described in OAS, but there is traffic to it. We define it as follows, using the “API Structure” we identify all routes based on traffic. After that, we load the specification and compare it with the constructed endpoint diagram. If there is traffic to the route, but it itself is not in the specification, then this is the shadow API. Such undocumented APIs are dangerous because they can fall out of sight of the information security department and security policies will not apply to them.
If there is a route in the loaded specification, but the “API Structure” does not record traffic to it, then this is an unused (orphan) API. The presence of such endpoints in the specification can make it difficult to monitor the entire infrastructure.
Finally, if an API was described in the specification, then removed from it, but the “API Structure” continues to record traffic to it, then a ghost API has been defined, i.e. an endpoint that is considered deleted, but in fact it is not disabled and continues to receive traffic. Such APIs are a weak point of the infrastructure, because… in the absence of regular updates, they become a vulnerable target for attack. You can learn more about the specification comparison feature in our documentation.
From the perspective of a company's internal processes, the API Framework is a tool that provides observability to your APIs. This will be useful for both the information security team and the development team. And thanks to the new features, you can conveniently and easily compare the specification generated at the API development stage with what you see in the traffic. This allows you to select those parameters and routes that need to be restricted. For example, this can be done using the virtual patch functionality that is included in the firewall from Webmonitorex, or it can be immediately transferred to the development team for correction.
We will discuss in detail the importance of API security in modern conditions at the webinar on April 17 at 12:00 (Moscow time). Here we will talk about the changing threat landscape and how these changes are reflected in the OWASP API Security. We will take a closer look at ensuring the security of web applications in the most attacked industries (telecommunications companies and Internet platforms). We will show how the Webmonitorex platform solves the problems of protecting web applications and APIs. Register by link.
API FIRST is closer than you think!
