An application programming interface (API) is a computing interface that defines and enables interactions between different software. Many everyday tasks occur thanks to APIs, including sharing media on social platforms, processing online payments, and aggregating website analytics data. With cloud computing, enterprises can more easily deploy global infrastructures with the help of APIs.
Today, the majority of software uses or is an API—and in the last 4-5 years, API growth has been exponential. For example, Postman, a collaboration platform for API development, saw its API folders count skyrocket from less than half a million in 2016 to nearly 35 million in 2020.
Despite the meteoric rise in API popularity, related security measures have lagged. Now, with the floodgates opening wider, a variety of major vulnerabilities have surfaced. Given the combination of explosive growth and underdeveloped security, APIs are predicted to become the biggest security vulnerability ever according to Gartner.
One of the main drivers of API growth has been the proliferation of microservices, which began to gain popularity in 2013. The microservices style of architecture develops small, individual applications that communicate with each other using APIs. This way complex tasks are broken down into smaller parts, and each part is developed and maintained independently.
The global microservices architecture market was valued at $2.07B in 2018, and it’s projected to reach $8.07B in 2026 (CAGR 18.6% from 2019-2026). Microservices have become widely adopted due to flexibility, faster development cycles, and superior scalability.
For example, to keep up with demand, Netflix departed from centralised monolithic data centres to a cloud-based microservices architecture. The result was tremendous freedom for developers to continuously improve customer experience, such as the ability to tailor content to specific geographic regions.
The trends that led to the API-first world we live in also give us a hint into where vulnerabilities are found. APIs are everywhere, and API growth continues to rise. Therefore, so does the risk.
Widespread API-related development and activity do not translate into secure applications. According to Gartner, by 2021, 90% of web-enabled applications will have more attack surface area in exposed APIs rather than in the user interface (UI). Gartner also predicted that by 2022, API abuses will move from infrequent to the most-frequent attack vector.
API vulnerabilities can be found across a wide range of areas, such as endpoints (devices, servers, virtual environments, etc.), data exposure, denial of service (DoS), authorisation flaws, security system misconfiguration and more. Considering the massive attack surface involved with thousands of API-supported assets found in any given organisation, API vulnerabilities can have extremely wide-ranging effects in an enterprise.
Examples include the destruction of data, stolen funds, lost productivity, intellectual property theft, personal and financial data theft, fraud, business operation disruption as well as the cost to restore and/or delete damaged data and systems. Reputational harm associated with API breach can also lead to the erosion of trust, which is common to any serious security event.
High profile cases, in which companies suffered API attacks despite having strong security measures, in general, have already made headlines. Looking at the Facebook example, 50 million accounts were exposed by attacking a weakness in the site’s “View As” feature. This allowed hackers to steal account access tokens after Facebook created an API-supported video upload functionality.
Uber was also exposed when their users’ universally unique identifiers (UUID) in API requests led to leaked tokens in the API response which could be used to hijack accounts. Attackers were then able to track victims’ locations and even steal rides.
Facebook and Uber cases demonstrate what is known as a ‘broken user authentication’ API attack. When authentication is implemented incorrectly, it allows for the compromise of authentication tokens and other flaws which enable user identity theft.
The heavy use of residential IP addresses due to increased home office work related to Covid-19 makes separating malicious API calls from legitimate ones even more critical. Credential stuffing or spam botnet attacks may use up to 10,000 different IPs consisting of hacked servers, workstations, and even IoT devices.
Since APIs expose application logic and sensitive data such as Personally Identifiable Information (PII), they are critical to an organisation's infrastructure and security strategy. But traditional web application security strategies — many of which rely on a “negative security” model — can fall short of stopping most API threats.
In a “negative security” model, every request is let through a Web Application Firewall (WAF) unless it’s on a blocklist of known or suspected threats. This model can create false positives — in which legitimate API calls are blocked — and may also fail to catch some of the more targeted attacks. However, WAFs do have a critical role to play in API security. For example, authenticated traffic which passes a few stages of schema validation — e.g. endpoint, method, and parameters — may still carry an SQL attack, which a WAF could catch. Additionally, some APIs are not suitable for TLS or pose schema validation challenges. If schemas are not up to date, or if APIs are fragmented and difficult to consolidate into a single schema, a WAF would help fill the gap.
That said, sole reliance on a blocklist-centric WAF for API security leaves an organisation vulnerable. API threat mitigation can avoid these risks with a “positive security” model, like API Shield, which only allows known behaviour while identifying and rejecting everything else.
One key step towards a positive model is deploying strong authentication and authorisation which is not vulnerable to the reuse or sharing of passwords — e.g. TLS or OAuth. Managing permissions and certificate sharing can be time-consuming, so developers should prioritise tools that simplify the allowlisting process as much as possible.
Of course, extracting a certificate from a device and reusing it elsewhere is not impossible. Developers also need a way to validate API calls themselves. Schema validation can do this by matching the contents of API requests—the query parameters that come after the URL and contents of the POST body—against a contract or “schema” that contains the rules for what is expected. If validation fails, the API call is blocked protecting the origin from an invalid request or a malicious payload.
While positive security through authentication/authorisation and API call validation is important, additional security measures are also necessary. For example, APIs are still vulnerable to volumetric attacks, brute force attacks, and credential stuffing. Therefore, DDoS mitigation and rate limiting remain necessary tools in an enterprise’s overall security posture.
Adding new security tools to existing ones like DDoS mitigation and rate limiting can create challenges. When API calls pass through many disparate tools, they become more cumbersome to monitor and log. In addition, funnelling traffic through different tools in geographically distributed data centres can add latency and slow application performance.
For these reasons, API security is best served by multiple security capabilities integrated into a larger edge network, offering advantages like:
Built for modern enterprise architecture, Cloudflare is making it simple to secure APIs through the use of strong client certificate-based identity and strict schema-based validation. An intelligent and scalable solution to protect your business-critical web applications from malicious attacks with no changes to your existing infrastructure.
This article is part of a series on the latest trends and topics impacting today’s technology decision-makers.
Learn more about protecting against API vulnerabilities in the 2020 Gartner Magic Quadrant for WAF report.
Get the report
Follow the Cloudflare Blog