By Lars Larsson, CEO of Varnish Software

Seven security features and best practices to build into modern API infrastructures

Lars Larsson

Application programming interfaces (APIs) have been around for decades but only with the rise of the FANG (Facebook, Amazon, Netflix, Google) companies over the last five years have new developments in cloud and mobile technologies really kicked-off. During this time APIs went from being development tools discussed primarily in tech circles, to being the business drivers of what is now defined as the API economy.

 Whether you believe analyst predictions, industry reports or trending topics – APIs are now among the most popular financial services technologies. No surprise when you consider that APIs are the glue that connect “things” and applications to the internet in a modern web architecture. Financial service companies access (or give access to) these things, applications and the data they generate in order to harvest new business opportunities.

 In the rather conservative financial services industry with many new challengers on the scene, APIs promise to inject new life into digital transformation initiatives that improve communications and services. In the midst of all the hype, however, financial services companies need to be mindful that APIs can also quickly turn into a weak security link.

 Today’s hackers aren’t just breaking into servers, they’re attacking how people communicate with infrastructure—exploiting billing systems, user signups and overall API infrastructure. With more levels of exposure, the first vulnerability hackers will seek to exploit will be the communication between applications, servers and other devices. Therefore, in financial services, security should always be built into an API infrastructure from the start.

 Below are seven security features and best practices financial services companies should include in their API architectures:

Basic authentication and authorisation

One important and often missed step in securing the API infrastructure is to add a basic  authentication and authorisation layer. Authentication confirms a person’s identity and can happen through API keys (which is essentially an authentication token). Authorisation 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.

 If a person triggers an API request (for example, if someone wants to access an application or database) this request is matched against a defined ruleset in the local database for authentication and authorisation. Who is granted access to what is defined here. If the lookup is successful, which means the user has been granted the right to access, the request will proceed. If it fails, access through the API is denied.

 Transport security through TLS/ SSL encryption

It’s not enough to use authentication and authorisation, but you also need to ensure that data travelling through the API is secured. That’s where Transport Layer Security (TLS), formerly known as Secure Socket Layer (SSL) and often referred to as TLS/SSL, comes into play. TLS/SSL are cryptographic protocols that provide communication security between two communicating computer applications.

 Full TLS/SSL support on both the server backend and client side should therefore be integrated into the API infrastructure. Nevertheless, as TLS/SSL protocols are continuously under attack, it’s important to pay attention to any new developments and versions out there.

Further you should verify the parameters of your TLS/SSL certificate to ensure they are working as expected.

 Data service instead direct data access

Users should not access the database directly but through data services instead. The reason behind this is that security policies like authentication and authorisation are usually enforced on the application layer and are often not supported by the database. To ensure that the defined access control rules are working correctly and important security concepts are supported, access should always go through data services instead.

Audit logs and hashing personally identifiable information

Audit logs provide you with information about what resources were accessed through the API. They include information on destination and source addresses, timestamps and user login information. Audit logs help to discover if an application is or has being attacked. The level or extent to which a company should run audit logs depends on whether applications or information accessed through the API is mission critical or security sensitive. However, it’s important to ensure that any personally identifiable information (PII) is removed or encrypted. One way of doing this is to hash PII, which basically means that a piece of text is transformed into turning into non-identifying data, usually numerical values.

 Web application firewalls (WAFs)

A WAF is a kind of firewall that applies a set of rules to an HTTP conversation. It controls the access to an application or service by blocking any API call that does not meet the configured policy of the firewall. WAFs are good complements to secure your API infrastructure.

 Update and patch management strategy

Very often hacks occur through vulnerabilities that are not only already well-known but for which security patches exist. With an update and patch management strategy in place those security hacks can be reduced.

 Best practices for specific platform/development stack

Finally, to ensure the security of your API infrastructure, a rule of thumb is to always follow the best practices of the specific platform in use and of the development stack.

 If designing the API infrastructure from the start with these security features and best practices in mind, financial services companies don’t need to fear that their APIs will turn into the weak link and can count on them as drivers of digital transformation initiatives.