info@yenlo.com
eng
Menu
API Management 6 min

Designing APIs with security in mind

Hans Bot
Hans Bot
Senior Solution Architect
API Security scaled

API Security One of the key functions of an extended API Management platform, is to increase the API security. In my previous post, I already discussed the Policy Management features WSO2 API Manager brings. And that’s at least a decent start to secure your API’s. Through policies you can enforce controlled access to application functions – without having to rely on a secure implementation. You can also enforce policies to prevent a message overload, potentially threatening the availability of your services.

But there is more to application security than run-time policies alone can bring. This blog discusses the potential to design inherently secure API’s.

Advanced API Management

One of the challenges with API’s is their potential to be implemented basically anywhere. Implementations may run inside a browser, in a mobile app, or on top of some client-side application framework. The implementations may consume your API’s from a local network, your virtual private cloud, or on the public internet. And their developers may be colleagues, professional third parties, or even citizens. Usually, at the design phase, you have not much clue about your audience, and you typically don’t want to constrain it by your design. Hence, an API should be designed in such a way, that you do not take anything for granted. And you especially cannot rely on any client-side security. Not even that client-side credentials are kept secure. That’s why you need inherently secure API’s.

1. Secure API design

There are a couple of strategies to enhance the security of your API’s. Like any security practice, API security starts with a solid design. In the API world, you want to minimize your parameter space to the bare limit. It’s a good practice to not ask for anything you can derive from the context. And it is a good practice to maximize the context you can derive information from. How?

In the API world, a lot of context can be entered in a web token. You know, the session header you exchange between an API gateway and the consumer application. You can enter a lot of state in the token. For instance, information about the developer, and the contract you’ve closed, but also about the user of the application, his customer ID, rating, age, and such. The beauty of the token is that you can generate the information from a reliable source you control or trust, and that you can digitally sign it to prevent any fraudulent changes to its content. If you want to keep the information secret for the client application, you can encrypt it. However, you also might want to share information to use in the application for the convenience of the end user. After all, why would you ask the user to register his email address in the application settings, if you’ve already registered it on your side? And as a bonus, you prevent a potential inconsistency, and all the trouble and frustration that comes with it. True, you will have to regenerate a token as soon as the user changes his email address, but as long as this doesn’t happen very frequently, that is not a major drawback. 

In many situations, a backend interface needs more parameters than the bare minimum you’ve opened up in the API definition. It’s one of the strengths of the API Gateway that it is able to augment the incoming parameters with information from the web token.  And this information is exactly as reliable as your internal source is. That’s reassuring, because no script kiddy can manipulate a parameter that is void by design.

By the way, should you need a parameter that changes frequently, such as the balance on a bank account, and you don’t want to carry that in the web token, you can still include a traditional data enrichment step in your flow. If it is a straightforward getter, the API Gateway may handle it in its mediation step. As soon as it exceeds the responsibility of the gateway, it’s better to offload it. 

2. Secure authentication

Talking about a secure internal source to establish the context of an end user, secure authentication quickly springs to mind. In today’s world, a basic authentication with a password or -phrase, simply doesn’t bring the degree of certainty that is needed to provide the privacy and confidentiality consumers and authorities expect.

Fortunately, WSO2 has got you covered once again. WSO2 Identity Server is a state-of-the-art Identity Provider, which integrates with WSO2 API Manager out of the box, and supports a number of advanced authentication factors. You can simply choose the ones that suit your business best. It could even be situation dependent, for instance, you can send a secret as a notification when the user is on his mobile device, and in an email when he is on his laptop. 

3. Managed self-service

One of the perhaps most under-explored areas of API security is an extension to the API Store, aka API Developer Portal. By design, the store is a self-service portal. However, there can be a number of reasons for more formal processes. The proper registration of a developer may require some validation or verification of his input. And in some cases, it might be necessary to close a contract, or at least confirm the terms of use. 

From a security perspective, this is just another means to create a reliable context – in this case the developer context. Hence, it might be a good idea to analyse the information you need to enforce your policies, and then decide what information you need to capture during registration of a developer (or during registration of his application, subscription to an API, …).

Currently, the WSO2 API Manager does not include a workflow engine to host your registration workflows. If you’re using WSO2 Identity Server, you could investigate using its workflow engine. This may suit simple cases. For advanced business process management, it’s probably better to look at WSO2 Business Process Server (now part of the WSO2 Enterprise Integrator package).

4. Advanced throttling

Throttling is the mechanism of choice to prevent your systems from overload (and the loss of availability that goes with it). In times of high demand, your resources are scarce, and you have to manage the scarcity. You may set fixed limits on the number of messages, but you may just as well monitor the average execution time and invoke a throttling policy as soon as the performance starts to plummet.

Anyway, to manage your scarcity sensibly, it makes sense to favor your most valuable customers – sometimes developers, sometimes end-users, sometimes a combination of both. And again, the information in the web token may include just the information you need to establish the value of an interaction.  

5. Supplementary protection

Sometimes, information you share through an API is too precious to rely on transport encryption only. There may be very good reasons why you need end-to-end encryption, i.e. uninterrupted from frontend to backend, where HTTPS is typically terminated on the perimeter. That is where secure messaging comes in. 

It is entirely feasible to encrypt the payload of a message you send to an API. Moreover, your API Gateway has no interest at all in the content of the message. At least, if you’ve designed your APIs properly, that is. Properly designed APIs act on message metadata only. That includes your HTTP headers – a typical mechanism to pass your software token. Which brings us back full circle.

Take away

At Yenlo, we know a thing or two about proper and secure API design. And we love to talk about it. So, in case you need help with designing your APIs for inherent security, or want to invite us for a second opinion, don’t hesitate to contact us. 

eng
Close