Building security into modern, high-performance API architectures

The following article appeared originally on the JAX Magazine website in the lead-up to the JAX Finance event in London, April 27-29, 2016, republished here courtesy of JAX Magazine.

Dev and product teams in Financial Services have a lot on their shoulders these days. Not only do they have to develop great products, they also need to support infrastructures that are fast, massively scalable and —above all— secure.

Today’s hackers aren’t just breaking into servers, they’re attacking how people communicate with infrastructure—exploiting the billing system, user signup and overall API infrastructure. Security breaches can occur when applications are reverse-engineered or when free users break open premium product services. With more levels of exposure, the first thing hackers will look into will be communication between servers, devices, etc. Therefore, in financial services, security should always be built into an API infrastructure from the start.

One important and often missed step in securing the API infrastructure is to add a basic authentication and authorization layer. Authentication confirms a person’s identity and can happen through API keys. Authorization confirms what that person is allowed to do and rules can be added to grant access to individual APIs based on the client’s identity. The following example of the Varnish API Engine illustrates how this can look in practice.

Example: Authentication and authorization with the Varnish API Engine

The open source HTTP engine/reverse proxy Varnish Cache is the core component of the Varnish API Engine. Though it is an infrastructure component, it has business logic in the shape of Varnish Configuration Language (VCL) in it. VCL is a domain specific language based on C that gives developers among others the possibilities to define access roles for the API.

Requests from your customers may contain an API key as the query parameter “apikey” or the request header “apikey”. Each incoming API request is matched against a defined ruleset in the local database for authentication and authorization.

The sequence that follows an incoming HTTP request through the authentication and authorization process look like this:

1. One of the Varnish Cache instances receives a new API client request, with an API key set as a query parameter apikey or as a request header apikey.
2. The API key (which is an authentication token), the requested host and URL are looked up in the local SQLite database. The request is authenticated if the lookup returns a match.
3. If the lookup returns zero matches, the request will be rejected with a “401 Unauthorised” response. If the lookup returns one match, the request is considered authenticated, and the request will be further processed. Consumer requests without the API key set, will be rejected by default.

The Varnish API Engine does authorization on a per-URL basis for each API key. This way, each API key can be granted access to various URLs with separate access rules and http method filters. If a known API key tries to access a URL to which it does not have access, the request will be rejected with a “401 Unauthorized” response.

Other security features and best practices

Apart from authentication and authorization, there are other security features and best practices that should be built into all modern, high-performance API architectures, such as:

• Transport security through TLS (SSL) encryption on all communication
• The use of proper client certificate management
• The use of secure data services instead of direct database access
• Audit logs to see who is accessing what (don’t forget to hash Personally Identifiable Information)
• Monitoring to analyse the request stream, and to have an update and patch strategy in place that can be complemented by web application firewalls (WAFs) to apply a set of rules to the HTTP conversations.

Finally, to ensure the security of your API infrastructure, a good work rule is to always follow the best practices of your specific platform and dev stack.

Hence, if API infrastructures are designed with security and best practices in mind from the very start, developer teams in financial services will have slightly lighter burdens on their shoulders.

Are you ready to learn more about the Varnish API Engine? Download our white paper.

Photo (c) 2006 reynermedia used under Creative Commons license.