Are your APIs a Security Threat? Secure your Data for the Future

APIs are among the most widely used tools for exchanging data between otherwise incompatible systems. Online banks use them to populate their smartphone apps, connected cars use them for navigation, and websites use them to embed data from third-party sources for a richer, stickier user experience.

By exposing a subset of a host’s data in a human-readable, tagged format, APIs let developers integrate remote data without needing to fully understand how the systems hosting them either work or are structured. They also protect the data owners by keeping their core systems and databases at least one step removed from any outsider who wants to access them.

Yet poorly maintained APIs can still pose a security threat.

Multi-layered security models

“Broken, exposed, or hacked APIs are behind major data breaches,” warns RedHat. “They expose sensitive medical, financial, and personal data for public consumption.” However, as RedHat goes on to point out, not all data is equal, or equally sensitive, and “maybe you don’t care if someone finds out what’s in your fridge, but if they use that same API to track your location you might be more concerned.”

Devising an appropriate model for securing any API should therefore concern itself, in the first instance, with the value and sensitivity of the data being transported.

At the most basic level, API keys can be used by the API gateway, which receives and interprets incoming API calls, to check whether a process should be authorised. However, without also verifying that the key is being used by the subscriber or process to which it was initially assigned, there’s no way to know that it’s not been shared or leaked, granting access to unknown or – worse – unauthorised users.

According to the Kafka website, 80% of all Fortune 100 companies use Kafka. One of the biggest reasons for this is that it fits in well with mission-critical applications that require the use of APIs in cloud agnostic environments. Find out how in this free download.

API risks to infrastructure

But, as F5 Labs explains, if there’s a vulnerability in the API itself, things could be a lot more serious than abuse of public data. “In [the] worst case, it’s not just your data that is potentially at risk but also your infrastructure.

By exploiting a vulnerable API, attackers can gain access to your network using one kind of attack. If they’re able to escalate privileges, they can then pivot to other types of attacks and gain a foothold in the network.

The right attack—often a multi-level attack—could potentially lead to your organization’s most sensitive data being compromised, whether it’s personally identifiable information (PII) or intellectual property (IP).”

API authentication as a form of security

As Netacea points out, API authentication requests are both difficult to separate from one another and easy to miss within general web traffic, which can make APIs a tempting point of attack.

API observation as a form of security screening

Using analytics to profile regular API use and comparing this over time may therefore provide the best chance of identifying anomalies, such as access from unexpected locations, that could hint at malicious intent.

But observation and API keys are just two tools in a wider range of options that API administrators should be using to protect their gateway and back-end services so they can keep their data safe. This should include limiting the amount of data exposed by the API, using asymmetric key or basic access authentication, and encrypting via TLS, according to API friends.

Protocols and security

By implementing multiple security layers, organizations can do much to protect themselves, their users and their data. For example, while requiring an API key is common, full authentication, requiring usernames and password, or OpenID can further restrict access. So can choosing an appropriate protocol. SOAP is often considered a more secure option than REST, but it can be more complex to work with, so is frequently seen as appropriate for use cases involving sensitive data.

SOAP and REST as security support

“If you need more robust security, SOAP’s support for WS-Security can come in handy,” says Stackify. “It offers some additional assurances for data privacy and integrity [and supports] identity verification through intermediaries rather than just point-to-point, as provided by SSL (which is supported by both SOAP and REST).”

SOAP and REST have been joined by GraphQL, which was originally developed by Facebook and released under an open-source licence in 2015. It allows for the retrieval of more granular data points, or multiple iterations of the same data type with a single query, which should reduce bandwidth consumption and, thus, make it an appealing option with the increased take-up of 5G.

Security measures for third-party GraphQL data sources

Businesses looking to work with third-party GraphQL data sources, or who want to use GraphQL to surface their own data should be aware of additional security measures, including, but not limited to, rate throttling and throttling based on query complexity, as well as timeouts to limit the potential for DDOS attacks.

Applying these limits is particularly important when working with GraphQL since, “Whereas with a REST API each HTTP request performs exactly one action, a GraphQL query can take arbitrarily many actions, and thus take an arbitrarily large amount of server resources,” notes Carve Systems.

“Because of this, the same rate-limiting strategies used for REST APIs – to simply limit the number of HTTP requests received – is generally not adequate for protecting a GraphQL API.”

Securing your data for the future

API use has shown steady growth over the last decade – and there’s no indication this is going to change. “There will be further growth in APIs [in 2021] where heritage systems will be augmented with APIs so that the capability/domain’s reach can be extended thereby avoiding the expensive and risky lift and shift to the cloud,” says Freeman Lightner.

Each of these new APIs has the potential to add another attack vector to the web, giving malicious actors the opportunity to access data – or systems – for which they haven’t been authorised.

While focusing on an API’s ability to extend the life of legacy systems, or to launch new and innovative services, developers must therefore remain mindful of the potential to expose more than they anticipated if they don’t employ adequate, multiple security measures appropriate to the data and systems involved.