Addressing Vulnerabilities and Abuse for Comprehensive API Security

As APIs emerge as a key lever for enterprise digital transformation, innovation and value, the proliferation of APIs has expanded the surface area for cyber attacks. In fact, Gartner's prediction that API abuses will become the most common type of web application attack resulting in a data breach by 2022 has been reinforced by a string of high-profile API security incidents in 2019.

Even so, API security still does not make it into the top 3 list of challenges in the 2019 State of API report from SmartBear. 

SOURCE: SmartBear

There were three separate instances just this year that shone a light on the creaky fundamentals of current API security.

In the first, researchers discovered – and notified – a pair of prominent online conferencing product companies that their APIs were vulnerable to enumeration attacks. Though both companies eventually addressed the issues, the general stand seemed to be that it was not a real vulnerability but an optional feature to improve user experience.

In a second instance, a security analyst used commonly available software tools to reverse engineer 30 different mobile financial services applications – in less than nine minutes each on average – to expose sensitive information, including personally identifiable information and account credentials.

Third, a detailed scan of GitHub public repositories earlier this year revealed that developers were inadvertently leaking thousands of API tokens and cryptographic keys in their source code.

All this suggests that API security practices are not keeping pace with the rapid and widespread deployment of the technology. A holistic API security posture must not only address API vulnerabilities, but also include detection and protection against API abuse and anomalies.

Distinguishing Between API Vulnerabilities and API Abuse

The Open Web Application Security Project (OWASP) recently published its first ever Security Top 10 list for API vulnerabilities that have caused recent data breaches and posed common security hazards. The list includes everything from broken authorization and authentication to excessive data exposure, lack of rate limiting, logging and monitoring, and improper asset management and security configurations.

Each one of these vulnerabilities can be addressed using currently available tools, solutions and security practices and a little diligence.

For instance, rule- and policy-based security checks are mandatory features of modern API management solutions. These solutions inspect incoming requests at API gateways to block a range of attacks such as SQL injection, cohesive parsing and entity expansion. Combining these modern solutions with some field-tested best practices – such as network traffic encryption with TLS, strong authentication and authorization controls for both end users and applications, applying quotas, throttling, and rate limits, as well as regular penetration testing across the API, the application layers and the backend – can help address almost every vulnerability in the OWASP API Security Top 10 list. These API management solutions and best practices will continue to evolve along with API technologies even as vulnerability-based attacks become more sophisticated.

Beyond this, there is the issue of API Abuse. These attacks do not depend on API vulnerabilities or implementation issues, relying instead on legitimate access to business logic and data in unexpected ways to undermine security.

A case in point is the ability of almost anyone to download an app and reverse engineer how the API works. Some app developers are already using API keys that compute at runtime as opposed to embedding them as static secrets in the code. It is also possible to add an additional layer of security by securing API keys using Mobile App Attestation solutions. This means that the API server only responds to requests from a genuine instance of the mobile app.

Limitations of Conventional API Security Solutions

The challenge with API abuse is that it is driven by ingenuity and inventiveness on the attackers’ part rather than by the carelessness or oversight of API developers and security teams. This is often where conventional API management solutions with rules - and policies - based security systems falter. For instance, API management systems can reject invalid logins, but they do not have adequate mechanisms to stop automated credential stuffing. Most API security systems also lack the capabilities to protect systems and data once a user is authenticated. At the same time, hackers are constantly deploying new techniques to avoid detection by keeping requests below rate limits, changing IP addresses, and by executing DDoS attacks from multiple clients. Even if it were theoretically possible to expand the scope and sophistication of API security by applying more rules and policies at API gateways, the additional overhead on the gateway would result in unacceptable processing delays for genuine users.

Though conventional API security elements like API gateways and WAFs provide baseline protection, there is only so far that a rules-based security model can be extended. Moreover, API security, especially in cases of API abuse, is not just about managing access but also understanding behavior. And that’s where context-based security solutions can complement existing solutions – namely, in providing additional data and factors which can be considered alongside rule-based protection mechanisms.

The Future of API Security

The conventional API security model is mainly focused on access control, load balancing and rate limiting, and communication and network privacy. As technologies and practices evolve, these foundational functionalities must be augmented with advanced capabilities that effectively address the issues of both API vulnerabilities and API abuse. Even as that happens, the broader discussion has to focus on the relative merits of applying positive vis-a-vis negative security principles to API protection, and on specifically how the two can be blended to create more robust security solutions for API management. It is likely that the conclusions derived from this discussion will be very significant pointers to the future general direction of API security.