This is the story of Company A and Company B, whose seemingly different web application and API security approaches share a subtle yet crucial flaw. This flaw resulted in data breaches (and all the associated negative outcomes) for both.
Company A has the most secure API protection possible. They block all schema violations, rate limit excessive requests, and use the latest threat intelligence to blocklist known malicious IP addresses. Their password-based API authentication could be more secure if it were replaced with mutual TLS, but they have never had a breach yet.
But their API security, threat intelligence feed, and WAF are all from different vendors. And thanks to vendor updates, the threat intelligence informing their API security is no longer compatible with their WAF, which protects their account login page. Consequently, an attacker is able to use a new SQL injection exploit on this page and obtain a legitimate user's username and password. The attacker then sends authenticated, schema-validated requests to their API, and obtains reams of sensitive data.
Meanwhile, Company B's web application is fully secured against DDoS attacks. Company B also exposes an API to paying users who want to integrate with Company B's application.
The attacker purchases a legitimate paying user's API key on the dark web. Armed with this key, the attacker launches a low-and-slow DDoS attack against Company B's API server. The attacker activates a bot that sends requests at irregular intervals. Each API request the bot sends is accepted as legitimate by the API server, because it comes with an acceptable API key. And unfortunately for Company B, their backend team forgot to proxy their API server through their DDoS mitigation provider — even though all their other servers are protected.
As the requests pile up on top of each other, the API server becomes overwhelmed, and finally cannot serve Company B's other users at all. Many of them cancel their paid accounts out of frustration.
What issue did Companies A and B have in common?
In these examples, both companies’ web application and API security approaches were patchwork combinations of solutions from multiple vendors. The solutions were not integrated and also prone to manual error.
To understand why this is a problem, consider the typical components of a web application and API security framework:
WAF: Blocks attacks against web applications and web properties
Bot management: Responsible for challenging or blocking probable malicious bots
DDoS mitigation: Keeps web properties online in the face of DDoS attacks of any kind (whether volumetric or low and slow)
API protection: Includes rate limiting, schema validation, authentication, and so on for APIs
Company A and Company B had adopted all of these protections. But because their web application security solutions were disparate (even if best-in-class), they had flaws that the attacker was able to exploit.
For Company A, both their WAF and API protection, being layered rather than integrated, had to face and block the attack. Attacks that one might stop could get by the other. Company B's DDoS protection did not protect their API infrastructure, their bot management did not detect API requests that originated from bots, and their authentication was weak and easily compromised.
These are just a couple of examples of potential gaps. Other common gaps in web application security include:
Limited threat intelligence: Threat intelligence that’s not up to date, does not go to the right place, or is not in a compatible format. This happened to Company A.
Too much threat intelligence from too many sources: Resulting in false positives, redundancy, and other inefficiencies.
Bot false positives: This can frustrate users, slow down service, and lead to lax enforcement.
Alert fatigue: The average enterprise uses 45 cybersecurity tools from multiple vendors, all generating alerts. Too many disparate products can lead to human employees ignoring threats in order to get their work done.
Insufficient authentication: Both Company A and Company B were vulnerable to credential theft in some form.
Non-scalable threat defense: Hardware security appliances bottleneck traffic and become overwhelmed during large attacks or with a variety of attacks.
These gaps are becoming even more risky as the complexity and sophistication of cyber attacks increase. Per McKinsey, attackers today "include highly sophisticated organizations that leverage integrated tools and capabilities with artificial intelligence and machine learning." Modern attackers are often moving faster and improving their tactics more quickly than their targets.
APIs are increasingly important to the modern organization's web application infrastructure. Today, 58% of all dynamic traffic processed by Cloudflare is API-based, and that share continues to grow. In fact, many organizations describe themselves as API-first. Moreover, Cloudflare blocks a greater percentage of API traffic as malicious than web traffic, demonstrating that attackers have APIs firmly in their crosshairs.
With APIs so often embedded deeply within web applications, their security must be paramount. Yet well-meaning internal teams often deploy APIs quickly — and often without consulting security. The result: Many web application breaches can be traced back to poor API security.
For instance, an API-related breach hit the USPS when an API that supported real-time package tracking was found to lack basic authorization. Logged-in users could query account information for any other user, via use of wildcard search parameters that would reveal all the records of the data set. This put the data of 60 million USPS account holders at risk.
What if, instead of using a patchwork of security products, Company A and Company B had combined all of their web application and API security services onto one consolidated platform? And those different services all integrated with each other? And data about the state of the company's infrastructure appeared in a single location, so they could quickly assess attacks and their security posture?
Company A could have ensured all their web application and API security framework components had the latest threat intelligence and stopped the attack before it started — since it would all be on one platform. Company B could have more easily extended their DDoS protection to all their servers.
Using a platform would mean easier management, with fewer gaps.
This consolidated approach to web application security requires highly scalable infrastructure, able to proxy all types of traffic. In previous decades, organizations bought appliances when they needed to defend themselves from new attacks, or when they needed to scale up. But a cloud-based service scales up more easily and should be able to proxy any type of infrastructure. And while a consolidated platform is no guarantee against all attacks, it certainly would have helped our hypothetical companies.
This is not merely a hypothetical thought experiment. Gartner defines these consolidated services as "Web Application and API Protection," or WAAP. In 2022, Gartner predicted that "by 2024, 70% of organizations implementing multicloud strategies for web applications in production environments will favor cloud web application and API protection platform (WAAP) services over WAAP appliances and IaaS-native WAAP."
WAAP is not just another acronym: Consolidating WAF, bot management, DDoS protection, API security, and other services is increasingly essential for modern organizations. The global nature of the Internet continually exposes web applications and APIs to attacks from many locations and various levels of scale and complexity. It is no surprise that in 2022, IBM reported that 83% of surveyed companies experienced a data breach, with breaches costing $4.35 million on average globally and $9.44 million on average in the United States.
If Company A and Company B were to build their applications and APIs from scratch today, they might host them entirely in the cloud, perhaps with one hosting provider for ease of deployment. But in reality, most organizations have deployed hybrid infrastructure with legacy on-premise database servers, cloud-based third-party APIs, and application services hosted in multiple clouds. These deployments offer many advantages but also come with security challenges of their own.
For instance, native security in a given cloud provider's offering may not extend to the entirety of their infrastructure. To begin with, discovering and mapping all their infrastructure in order to then defend it may also prove a challenge. And last, their security products may not be compatible with other solutions in your tech stack.
Therefore, in addition to consolidating crucial web application security capabilities, WAAP needs to be infrastructure-agnostic, meaning it has to be able to sit in front of any type of infrastructure or cloud deployment.
Cloudflare is cloud-native and infrastructure-agnostic, has offered web app security for well over a decade, and offers all these capabilities as one consolidated platform, within a single pane of glass. Cloudflare also has the advantage of seeing a large percentage of the Internet's traffic, serving over 63 million HTTP requests per second and blocking ~165 billion cyber threats each day on average. This gives Cloudflare unique visibility into zero-day threats and new attacks.
This article is part of a series on the latest trends and topics impacting today’s technology decision-makers.
Gartner recognized Cloudflare as a Leader in the 2022 Gartner® Magic Quadrant™ for Web Application and API Protection (WAAP).
After reading this article you will be able to understand:
How disparate security solutions can create security gaps
Examples of how these gaps might manifest
Why Gartner recommends consolidating with a infrastructure-agnostic web application security platform