More than two decades ago, Jeff Bezos declared that all Amazon teams would be required to “expose their data and functionality through service interfaces” — no exceptions. The memo (now known as the “API mandate”) essentially stated that application programming interfaces (APIs) are not optional — and it helped spark a race for developers everywhere to connect everything via APIs. Yet, for many organizations, API security has fallen behind the fast pace of API deployment.
API-related traffic now comprises the majority (approximately 57%) of all dynamic Internet traffic, according to the recent 2024 API Security and Management Report. But, businesses commonly find themselves struggling with challenges like:
Invisible, unprotected attack surfaces: IT and Security cannot defend what they cannot see — and organizations have “shadow APIs” — APIs that their IT or security teams aren’t managing — leading to data exposure, lateral movement, and other cyber risks.
Overly permissive authorization: In the wrong hands, ‘write’ access to APIs that were originally intended to be read-only leaves systems vulnerable to attacks and potential data loss. Yet, nearly 60% of organizations permit ‘write’ access to at least half of their APIs.
Organizations can easily overlook and misclassify the causes for API-related errors: Not all API errors are caused by attacks, and not all attacks on APIs can be mitigated the same way. An error or vulnerability that is missed or misdiagnosed can lead to a poor end-user experience, or — worse, a cyber attack.
There are an estimated 200 million public and private APIs in use, and growing. To securely leverage the power of these (and future) APIs, organizations need a purpose-built API management approach that incorporates the following 3 “do’s” and “don'ts.”
Let’s say Acme Hospital offers digital initiatives that their patients and providers love: everything from seamless mobile telehealth to AI-assisted record processing. One day, one of the Acme’s developers enables “write” access to a billing system’s API without proper documentation. A few months later, the vendor gets hacked — then, through lateral movement, attackers are able to exploit Acme’s public API to breach the hospital’s patient records.
Acme could have detected and mitigated this scenario sooner if they had a way to automatically:
Discover all public API endpoints (including unauthenticated APIs) and related traffic
Detect API schemas — the metadata that defines the specifications of a valid API request/response)
Detect attack variations on APIs
Enter: API security solutions that utilize machine learning models, and do not require manual, “point-in-time” communications between IT, Security, and Developers.
For instance, machine learning-powered API discovery and API schema detection can give organizations like Acme a more complete inventory of their APIs: What are those APIs? What data and systems do they access? When and where are they being accessed? Who has been granted “read-only” vs. “write” permission?
This kind of data is critical for preventing the proliferation of shadow APIs. In the process of developing new customer functionality (that is often exposed as Internet-facing APIs first), the API documentation and security ‘best practices’ are usually left up to the discretion of individual developers. Many times, there is not enough time or resources to bring in the security teams.
That is why security challenges emerge: organizations cannot protect what they cannot see. In fact, Cloudflare’s machine learning models uncovered 31% more API endpoints than what organizations self-reported — suggesting that nearly a third of APIs are essentially shadow APIs.
Shadow APIs (often benignly introduced during frequent code changes) are not inherently malicious. But, when you consider that 86% of developers do not view app security as a top priority, shadow APIs are a top threat. If exploited, they can lead to data exposure, unpatched vulnerabilities, data compliance violations, and other risks. Machine learning helps bring those shadow APIs out of the dark.
Web apps and APIs are fundamentally different. A ride-sharing app is ‘visible’ to its users, but the API that gives the app access to Google Maps data is ‘invisible.’ Given these (and other) differences, organizations need purpose-built API security, not just web app security, to protect APIs.
For instance, a traditional web application firewall (WAF) filters and monitors HTTP traffic between a web application and the Internet based on a blocklist. The WAF looks for known signs of an attack, then takes action to stop those attacks. All other traffic is permitted. This is the “negative” security model, which can be effective for web app security where it’s easier to identify and block malicious web traffic.
However, protecting APIs from abuse — API security — requires “positive” security. Instead of just looking for “known bad”, look for “known good” requests and only let those through: block everything else. (Learn more about what defines these requests – i.e., API calls — here).
Why?
Consider the example of an Australian telecom provider who experienced a breach exposing the data of nearly 10 million customers. The hacker had accessed a certain customer database via an unauthenticated API. While the full details of the attack are unknown to the public, it is worth noting that a “positive” API security model would have only permitted API traffic that conformed to the company’s API specifications.
In other words, turn to “positive” API security and only allow traffic from authenticated users, from authenticated corporate networks, taking authorized actions. (Organizations can also combine security models, such as layering the “negative” security of a WAF with the “positive” security of an API gateway.)
Bottom line: APIs require a comprehensive approach to defend against a wide array of API threats, which include the following 6 top API threats:
Source: 2024 API Security and Management Report
As identified by the chart above, HTTP anomalies comprised the majority (60.7%) of mitigated API threats. HTTP anomalies (such as missing user agents — the software that retrieves Internet content for end users — and other anomalies) are common signals of malicious requests.
By applying “positive” security (as described earlier), organizations can identify HTTP anomalies and other threats, and only allow “clean” traffic for each API to their API servers.
IT, Security, and Application Developers should share responsibility for protecting the massive attack surface involved with having thousands of API-supported assets. Yet, these teams’ priorities often conflict:
73% of developers say that the work or tools their Security team requires them to use “interferes with their productivity and innovation.”
87% of CIOs believe Software Engineers and Developers “compromise on security policies and controls to get new products and services to market faster.”
Only half of CISOs feel that Developers are “very familiar” with the security risks of development and workflow tools.
As a result, organizations may experience “tradeoffs” between innovating faster and improving security, leaving their APIs vulnerable. According to the report, nearly 60% of organizations permit ‘write” access to at least half of their APIs — but who ultimately “owns” making sure that “write” access is not given to the wrong user?
For the enterprise that keeps exposing new services via API, a connectivity cloud can serve as that connective tissue between app deployment and API defense-in-depth.
A connectivity cloud is a unified platform of cloud-native services that simplifies secure “any-to-any” connectivity across IT environments. In turn, this helps organizations regain control and visibility over their sprawling digital domains — including their API traffic.
With a connectivity cloud, organizations can tackle the following efforts (and more) using a single control plane:
Automate API discovery and visibility to give all stakeholders a clear inventory of their API estate
Modernize API authentication and authorization processes from the outset
Manage API endpoints to monitor metrics such as latency, errors and error rates, and response size for API-driven domains
Protect against API Layer 7 (L7) threats such as DDoS attacks, brute-force login attempts, and other API abuse
API technology is not new, yet holistically addressing API security is new to many AppSec and AppDev teams. However, all progress starts somewhere, and API security can be tackled in stages:
Stage 1 - Visibility: Start by identifying all APIs used within your organization. Use API discovery tools, review technical documentation and agreements, speak to your developers, and monitor your web traffic.
Stage 2 - General web attack protection: Web applications and APIs often work together (for example, an ecommerce website using an API to process payments). Use and integrate tools directly designed to protect web apps (and to an extent, the APIs behind them) from DoS and DDoS attacks, credential stuffing, zero-day vulnerabilities, and other threats.
Stage 3 - Consolidated advanced API security: Cloudflare’s Web Application and API Protection (WAAP) portfolio, powered by a connectivity cloud, provides holistic security and performance around public-facing APIs without inhibiting productivity. With API discovery, integrated API management and analytics, and layered defenses, Cloudflare enables IT and Security to gain visibility and control over their APIs.
This article is part of a series on the latest trends and topics impacting today’s technology decision-makers.
Get the 2024 API Security and Management report to explore the most common API vulnerabilities, industry predictions, and more in-depth recommendations for protecting APIs.
After reading this article you will be able to understand:
3 common API-related challenges
The “do’s” and “don'ts” of purpose-built API management
How to improve API security maturity over time
入门
资源
解决方案
社区
支持
公司