API security: what about traffic management?

Before digging deeper into traffic management aspects we will take a look at the requirements that drive the choice of implementing specific traffic management controls.

The following requirements are often heard during discussions with our customers when we are talking about API security:

• We want to have guaranteed availability of our APIs & our back-end services acting as a provider to our APIs.
• Our APIs need to be protected against malicious attacks from our API consumers. An example can be a hacker that is using injection techniques to make modifications to one of your organisations most valuable assets: data. This is where threat detection & prevention come into the picture.
• We want to rely on network segregation to apply different security patterns. For example: APIs exposed towards external consumers, i.e consumers that are not under our control require a higher level of security & threat protection compared to the APIs that we expose towards consumers we trust.

But how can we make sure these requirements can be met?

Suppose your organisation has gained some experience with building APIs for internal usage and starts looking at how APIs can play a role in your business partners ecosystem.

When exposing APIs towards business partners we don’t have control over their applications that will be using our APIs. Although authentication & authorisation are key players when it comes to protecting your partner APIs, we still face the risk these partners are launching a lot of API calls or even launching attacks towards our APIs.

One might think: “this is something that will not overcome us because we trust our partners. By adding authentication & authorisation to our APIs we are well protected”. You might be wrong! Although you trust your partners, they are not always intentionally doing things wrong. Think about a programming error in your partners’ application with a lot of API calls as a result. Even your partners applications are vulnerable to hackers. Malicious requests to your organisations’ APIs can be launched from your business partners as well!

As you can see, authentication & authorisation are not sufficient to protect your organisations’ assets.

This is were rate limiting & throttling come into the picture. Rate limiting helps you to block requests which exceed a specific SLA, whereas throttling will slow down requests which exceed a specific SLA. Both capabilities will help you to protect your backend services against too much load and consequently performance degradation. They are configurable policies on API level on the API gateway.

Rate limiting & throttling form a first line of defense against malicious API consumers, but what if hackers are using one of your business partners applications to launch malicious attacks towards your APIs?

API gateways typically come with a lot of other traffic management capabilities to help you protect against such threats. They come with policies that will help you to protect your APIs against the following attacks:

• Injection attacks: attacks where data is added in a request that is not allowed by the security policies that are applied. By the execution of message validation, an API gateway helps you to protect against such attacks.
• Parser attacks: attacks where messages contain data that puts too much effort on the parser responsible to process the message, resulting in unavailability of the service.
• Protection against CSRF (Cross-Site Request Forgery) and XSS (Cross-Site Scripting)
• Protection against viruses in attachments: some API gateways are able to integrate with virus scanning solutions and are able to scan attachments on the fly, even before entering your IT environment. Just like other attack policies, this can be enable on API level.

This kind of capabilities also come in the picture when exposing APIs towards the public community.

We have been talking about traffic management capabilities that are applied on API level, but some of them can also be applied on transport / network level. Let’s go back to the use case where you have gained internal API knowledge and you are ready to build your first partner API. It can be the case you have a VPN connection between you and the partner, but in many cases connectivity will be done over the public internet. As a result, your API will be made visible to the public community, with all potential security risks as a consequence.

With partners connecting to your APIs over the public internet you want to keep control over who is accessing your APIs. This is where IP whitelisting or two way SSL/TLS come into the picture. Both capabilities can either be implemented on an API gateway or on another network component like a Web Application Firewall.

Imagine you as an organisation decided to offer APIs to the public community and that you have taken all possible security measures on traffic management level to protect your APIs & backend systems. But what if it goes wrong? What if, despite all possible security measures, a malicious API consumer is still able to break through your API security line of defense?

This is where logging & monitoring kick in. They give insights into the usage of your APIs, like how many times APIs have been used during a specific time period, but it also gives you an audit trail on who has been accessing your APIs and when they have been accessing them.