Companies move to APIs, so do the bad guys

The use of APIs has increased and evolved tremendously in recent years, driven in part by mobile apps and the automation of processes across multiple applications. As with all new rapid developments, we also see new vulnerabilities emerging and security often lags in response. This new type of vulnerabilities, meanwhile, can also be found in the published OWASP top 10 vulnerabilities for APIs.

Keeping this in mind, Gartner predicted that by 2022, API attacks will become the most common type of attacks.

APIs are a critical component in digital transformation

The context of the digital transformation to an organization with high adoption of DevOps and microservices, almost certainly leads to less visibility on applications which are deployed by autonomous teams. Assurance of the necessary security is not guaranteed and the lack of the technical frameworks around this are a recipe for legitimate but potentially risky business applications. According to the DevOps way of working, the team is in the lead and responsible.

APIs are no exception to this, and it is difficult to know which APIs exist within the enterprise. According to Akamai, API traffic accounts for more than 80% of all Web transactions. All modern enterprise pipelines are built on APIs that interconnect and exchange data (REST API, gRPC and increasingly GraphQL).

We can define three types of APIs:

- Open (public) APIs: anyone may access these APIs and develop applications on them

- Semi Open APIs: this type of API is often opened to specific partners

- Closed APIs: these APIs are for internal use only, which does not automatically mean that they cannot be publicly unlocked.

Respectively, you can see that the degree of security measures for these different types often increases to ensure the secure operation of the service. Therefore, it is good to classify an API for a certain type of use and stick to that and create a new API with specific measures appropriate to that use. So even though the APIs have almost the same type of functions it is still good to maintain different APIs for the different types of usage. This reduces the chance of being pushed into a situation where, to keep or make things workable, security is put at risk. Make sure that in your development of the API you keep a sharp eye on this and analyze with every expansion by threat modeling to ensure that no new threats arise because, for example, an API starts handling a new type of data or acquires new functions that in turn carry risks.

API gateways and management solutions are essential for an API first strategy

Within an organization, multiple sets of applications are used to function properly. The digital transformation of a company like NS is complex requires well thought-out solutions that must be flexible and agile but also robust and secure. Consequently, these solutions also mean that connections between the various applications are increasingly needed and therefore the use of APIs is also increasing. To keep track of this, solutions are needed.

For API security, we distinguish two main solutions:

- API-gateways

- API-management

API gateways are usually at the end of an upstream flow of APIs to be protected. Within the gateway, features such as access control (authentication & authorization), rate limiting, and IP address filtering are present. Sometimes WAF (Web Application Firewall) functions are also present that can also block attack patterns (injection). This does not excuse us from developing secure APIs. WAFs are basically more suitable for Web applications and block e.g., SQL injections in HTML or JavaScript code and somewhat less set up for REST, SOAP or GraphQL command/code injections.

API management allows us to manage and monitor APIs. These platforms often provide a service portal for developers and administrators. These platforms do not otherwise directly interact with traffic for the API but provide a platform for versioning APIs and publishing to production. In addition, policies can be used to build in controls on, for example, the proper use of a JSON or XML schema.

APIs are linked to specific security issues

Without the use of the above-mentioned solutions, it is very difficult for an organization to maintain visibility and control over the APIs and the creation of “shadow” APIs is almost inevitable. Development teams are under increasing pressure to deliver new features and versions faster and faster to meet business goals. As a result, there is a temptation to ignore certain security-related issues. APIs are deployed in different environments by different teams and there are silos between the teams responsible for them. On average, about 30% of all APIs are characterized as “unknown” and are implemented outside standard processes or not accessed through the organization’s API gateway. Often APIs are also seen as “nobody knows about it,” because the API is only used via a mobile app, for example.

For public APIs especially you see that a certain guaranteed availability is important, and you will have to arrange things so that the API cannot be overloaded, by means of measures such as rate limiting. After all, you do not know who uses the API and how often these people will query the API. With API management solutions you can use monitoring to form a baseline that gives you a picture of the average and maximum number of requests per minute, which you can use to set rate limits. In addition, you must have good input validation, whether supported by WAF functionality or not. When injection attacks have a chance of success, the impact can often be incalculable and at the very least have an effect on availability. You must assume that these types of attacks on public APIs take place daily.

For semi-open and closed APIs, the focus is on access control since the risk of abuse is lower. Authentication on APIs, however, is often much more difficult. Whereas for web applications two factor authentication can be considered general, in the case of APIs it is certainly not obvious. However, this is not less important here. After all, how do you keep control over your semi-open APIs when the credentials are transferred to your partner, and you lose track of who gets to see those credentials or where they are registered?

Precisely because of these aspects you see that the “bad guys” are increasingly using APIs, partly because searching the internet for APIs and fuzzing can be automated to a large extent. By focusing on clear frameworks for the teams around measures to be taken, security testing and monitoring, and supporting them in this as needed, you maintain the autonomy of the teams and stay ahead of the bad guys. You do not have to be the best at this, as long as you do it better than others.