Due to the fast development approach adopted by most of the organizations, the modified SDLC is used for the software development. According to the project’s requirement, the modification is done and the new approach allows to align API proxy deployment for better development and maintaining the Security of the applications. Matrix Marketers, a web development company applies the same method for the development of small to big software projects. We need to accept a fact that the web application can’t follow one single software approach due to the multiple functionalities involved in one single application. Also, the application has to run on more than one platform.

Matrix Marketers team is showing in this post the different options which can be used for the API management to ensure security.

Key Issues in API Management

In the APIs, one key property is often observed that it is not possible to deploy any predefined virtual network. In the APIs designing, a location tracker is installed which allows opening the customized location for the users accessing the applications form different locations. As a Result, the application needs to communicate with API through a Backend service via a public IP address. The provision is made which allows you to talk to API directly to backend services but then you need to allow multiple sessions and the overall management will become difficult. Also, there will be the delay in opening the application. You will always want consumers to go over API Management to be able to use the API security. Thus, we have to look at different approaches to secure your backend services from direct access.

We will check out the following possibilities:

VPNs could be the first choice but that is fully a separate setup and much dependent and on the hardware setup that the software management. Here in this blog, we are focusing on the software management of the APIs.

Security by obscurity

Many experts suggest that it is not wise to allow users to directly communicate with the backend services. Also, it is quite obvious that no security standards can ensure that the application will be fully secure. A header could also be added to the backend call, using an additional secret key which tells the backend service that it is actually API calling the backend service. The drawbacks of this are quite obvious:

• You have to implement the header check in your backend service

• You have a shared secret between API and backend service concerned with the application

• The secret has to be deployed to API and backend service simultaneously.

• It is only secure if the connection between API and the backend service is using https transport (TLS)

Basic Authentication

The second variant of “Security by obscurity” is actually equivalent to using Basic Authentication between API and your backend service. Support for Basic Auth is though implemented API directly so that you do not have to create a custom policy which inserts the custom header into the backend communication.

Once more, the very same drawbacks apply as for the above case:

• You have to implement the Basic Auth in the backend

• You have a shared secret between the API and the backend

• If you are not using https (TLS), this is not by any means actually secure

Mutual SSL

The mutual SSL can secure API and backend services. All you need to do is get the certification and authentication to use the APIs. Some additional programming is required to be done to adopt this approach but that doesn’t matter when you talk about the security of the app. Some drawbacks to implementing this approach are:

Checking the certificate in the backend can be simple or challenging, depending on which kind of backend service you are using:

Apache web server also directly supports Client Certificate verification

Spring Boot: Intended way of securing the service, see e.g. Spring Boot Security Reference

All in all, using mutual SSL is a valid approach to securing your backend; it offers real security. It will still be possible to flood the network interface and thus could possibly be combined with the below method additionally.

Virtual Networks and Network Security Groups

In case your backend service runs using a virtual resource manager, you can make use of the built-in firewall for network security. As of the Standard Tier (which is the “cheapest” one you are allowed to use in production), your API instance will get a static IP; this IP, in turn, you can use to define an NSG rule to only allow traffic from that specific IP address to go through the NSG. All other traffic will be silently discarded.

As mentioned above, it’s unfortunately not (yet) possible to add an APIs instance to a virtual network, but you can still restrict traffic into the NSG by doing IP address filtering.

Conclusion

For critical backend services, use a combination of Mutual SSL Inbound NSG rules limiting traffic to the APIs IP address. In case need to use Web Apps/API Apps, consider provisioning an App Environment which you can deploy into a virtual network. For less critical backend services (such as read-only APIs), choosing the NSG rule option only may also be lightweight and easy to implement option. The only prerequisites for this are: Your backend service must run with the help of the resource manager virtual network.

In the present times, it is just to ensure that the security issues are properly addressed and attention is paid to the fact that even the simplest application needs to communicate to the outside world. Only the experienced developers can build such applications. Hire such a team from Matrix Marketers!