Let's take a dive into API security. In this article we explore the history of APIs, available tooling, and all the components-not just the endpoints-that need to be considered to set up and maintain secure APIs.
APIs are a common term within engineering, data analyst and business intelligence circles. They power the most successful partnerships between enterprises today. They are also key to scalable intra-organizational information exchanges. Everyone uses them, or should use them, to define a well-defined, controlled way for people or processes to interact with systems to supply or extract data.
While the road to define the technological details of APIs was rocky in the past, with many different standards, we have finally arrived at REST APIs as the de facto standard for web API calls. Ways to streamline the often cumbersome creation of calls via HTTP-libraries or `curl` commands have been developed and converged in the creation of Swagger/OpenAPI, which allowed for the easy translation of API definitions into SDKs. The standard is now at version 3.0, and it allows a clear definition of each endpoint, responses, security guards, schemas, parameter definitions, and much more (Specification here).
The standardization is helping, but it gives users full freedom to do things which may violate security or other best practices developed for APIs in the past, and sometimes even go against the idea behind certain HTTP operation definitions. Furthermore, one should never forget the different applications powering your API when producing threat models.
API security is a significant enough topic to have its own OWASP Top 10. It is to be noted that the API top 10 has a very great intersection with the general top 10, but the details matter in the way the risks and remediations are described.
With that, a selection of different tools has been developed, naturally starting with linters, aiming at detecting violations to common API security and general best practices. These are mainly focused on either the code or the OpenAPI specification itself. Examples can be found in this comprehensive list.
As we have mentioned since the inception of CoGuard, one should not look at tooling in an isolated manner, but at the interplay between the different involved tools which provide a solution. By looking at the API definition or the SDKs, one may miss the business critical components behind the APIs.
In essence, an API provides a well defined interface to obtain or alter certain information. Underneath may be something as simple as fetching a file from a file-system, or something as complicated as an Extract-Transform-Load job from a data-lake. In either case, there are other dependencies which pose a potential risk for security, and which need to be hardened. Solely focusing on the endpoint would be the API equivalent of a network design allowing all operations as long as the requests come from within the network, and securing only the outside endpoints.
In particular, underneath the API call may be tooling of the following types:
If the correct setup and security for each individual tool is not done, your organization’s data is at risk, and the whole setup is as secure as its weakest link.
Hence, every layer needs to be considered, along with the tools in isolation, and their interconnection. It needs to be established that the load balancer in front of the API has a web application firewall enabled, defending against common injection attacks as well as throttling traffic spikes from individual sources and timeouts. The authentication to back-end services needs to follow role-based access control principles to minimize the data exposure. Secret handling needs to be in place. And all that in addition to the common API specific flags like existence of schemas, security, default responses, etc. In order to serve all possible API functionalities an organization can have, the list of tools and their configurations which needs to be scanned in an automated way needs to be comprehensive.
And this is exactly where CoGuard sees its place for API practitioners. From the cloud layer, to the OpenAPI layer, to a long list of back-end services whose configurations it can understand and contextualize.
API definition and design does not only involve endpoints. It is an ecosystem of different tools involved. Their correct, reliable, and secure operation is at the center of all efforts. There is more to remember than an engineering team can keep in mind, and automation is the key to succeeding the management of APIs at scale. Do not stop your security considerations at your OpenAPI specification layer. Have a well rounded, comprehensive view on your security.
__________________________________
Happy to talk more: albert@coguard.io
Connect with me: https://www.linkedin.com/in/albertheinle/
```
pip install coguard-cli
coguard folder <PATH_TO_YOUR_REPOSITORY>
.png)
