Countering threats: Steps to take when developing APIs

High profile data breaches resulting from faulty APIs continue to make headlines. In the last few months alone, T-Mobile’s data breach resulted in hackers stealing personal data of more than two million customers while Google shutdown the consumer version of Google+, citing a bug that exposed the personal profiles of up to 500,000 users, with the API at fault used by up to 438 applications.

Privacy and security issues stemming from API development have continued to rise over the last year, with Gartner predicting that it will be the largest source of data breaches by 2022. But without a deliberate, focused effort to protect these systems, even that timeline seems optimistic. To counter this threat, businesses need to follow these three steps when developing APIs.

1. Only store the data you need

Storing data on customers and employees provides benefits from both a marketing and functionality perspective. But, for too long, organisations have collected unnecessary amounts of data, which if compromised, can result in damaging financial implications. According to IBM and Ponemon’s 2018 Cost of a Data Breach Study, the average cost for each lost or stolen record containing sensitive and confidential information increased by 4.8 percent year over year to $148. With millions of records compromised in each breach, the total becomes astronomical.

This year’s Facebook and Cambridge Analytica scandal is a clear example of this data misuse. The social media giant collected and shared large volumes of redundant data, which led to a third party having the ability to take action on information that they should not have had access to.

Match.com’s glitch this year is another example. A high number of old profiles, some that had been inactive for over 10 years, were reactivated on the dating website. With so much unnecessary information still stored, we can only assume they still have every message between those and every other user. If Match.com was hacked, it would compromise confidential data it should no longer have. Businesses need to learn from the fallout of these two issues, otherwise any API hack would result in dramatic consequences.

2. Make security the number one priority

Developers have often built with a feature-driven mindset, where functionality has taken precedence over security. Unfortunately, in today’s security landscape, vulnerabilities and threats lurk at every corner and have ever-growing consequences, so we have to turn this on its head. It has become even more of an issue in the race to comply with new legislation, which has left holes where hackers can exploit potential data.

This is counterproductive and can cause additional issues for organisations. Most recently, the Financial Conduct Authority (FCA) announced it will force UK banks to publicly reveal the number of IT outages they have via an API, showing the importance of open and reusable data provided via APIs. We’ve also seen the implementation of GDPR, where data breaches will now result in major financial fines on top of the reputational damage they cause. As other jurisdictions consider similar rules, the legal and financial consequences will only grow.

3. Take a unified approach

There are myriad approaches to API security that businesses currently take. They need to move away from unqualified trust and API Keys, which expose sensitive data. If you have an API, you must assume that others will find it and try to abuse it. Using an API gateway is a useful and valuable step but, when used alone, they do not give businesses the full context of the user, their session, and the connecting device. They lack the ability to differentiate between a user on the trusted computer at their office versus a suspicious mobile device on the other side of the world.

There is another approach that businesses should be following – the industry standard, OAuth 2.0. It works like a hotel check-in experience, where key cards provide select access to portions of an application depending on your permissions. Specifically, access tokens, granted by an Authorisation Server upon proof of identity, allow access for the specified user to a specific set of resources, with an automatic expiration.

OAuth is a more complex approach but allows far greater flexibility through structured consistency – an unquestionable benefit in the world of security. It’s important to remember, however, that OAuth 2.0 is still not a complete solution for securing APIs because it does not address how to protect the API itself. Just like any other system in our infrastructure, we have to defend our API from malicious users and poor software regardless of how they approach it. A great lock on the front door isn’t enough if we leave the windows open.

To make APIs as secure as possible, it’s important to combine API gateways with OAuth. The two technologies complement each other to create a powerful API Access Management solution that can limit particular OAuth scopes to specific devices, a specific network or group membership. They also have the added benefit of enabling a security team to manage policies like this outside the API Gateway, while centrally logging access requests, grants and policy changes.

Hackers are sophisticated and are constantly looking into new ways to break down defences and access valuable data. There is no silver bullet to stop them but organisations can start by limiting the data they are storing. If the organisation isn’t storing it, it can’t be leaked. When it comes to developing APIs, businesses need to make security the number one priority and ensure that they’re combining API gateways with OAuth 2.0 to strengthen API security.