Lighter burden on dev teams' shoulders

Building security into modern, high-performance API architectures

Federico Schwindt
Security image via Shutterstock

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.

    Blockchain Whitepaper 2019

    Free: Blockchain Technology Whitepaper 2019

    If building a blockchain from scratch is beyond your current scope, the blockchain technology whitepaper is worth a look. Experts from the field share their know-how, tips and tricks, development advice, and strategy for becoming a blockchain master.


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.

Federico Schwindt will be delivering one talk at JAX Finance which will focus on how Varnish Cache, the open source HTTP engine delivers fast, reliable web content at scale and provides a critical layer of protection for an API architecture in Financial Services.


Federico Schwindt

Federico is currently a senior software engineer at Varnish Software and for more than fifteen years a developer for the OpenBSD project.

Inline Feedbacks
View all comments