Why does WAF matter in API security?

Nowadays, APIs power the internet. We see APIs (Application Programming Interfaces) everywhere: webshops, social networks, mobile apps, government sites and most of the media entertainment is delivered to us over APIs. This is why APIs are so important and also why protecting APIs is fundamental for every organization being on the internet.

According to OWASP Top 10 API Security Risks 2023[1], 4 of the top 5 security risks are related to authentication and authorization, however by October 2023, the U.S. SEC launched an investigation around the MOVEit mass-hack that has exposed the personal data of at least 64 million people[2]. Considered the biggest hack of 2023, it began by exploiting a previously unknown SQL injection vulnerability in MOVEit Transfer. On the same line, cvedetails.com reports that the majority of CVE security vulnerabilities in 2023 came as Cross-Site Scripting (XSS) attacks, followed by memory corruption and SQL injection [3].

While identity and permissions are the foundation of API security, footprint attacks (XSS, SQL injection, Remote Code Execution etc) are still leading the game when it comes to security breaches hence the importance of protecting our APIs looking at the footprints.

Web Application Firewall (WAF) as part of a wider solution

No security layer can address all possible attack vectors, there are different layers of security with different concerns which sometimes narrowly overlap. A multi-layered strategy that acknowledges the complexity of the threat landscape is preferred, hence the need for a diverse array of defenses where each layer is a barrier to attacks, and together, they create a resilient shield capable of adapting to the shifting tactics of adversaries.

WAFs are proxy-based tools that mainly inspect incoming HTTP(S) requests. Its capabilities vary, however the basic function is to provide an application layer filter for web and API traffic. This stage looks for malicious and unwanted content within incoming requests (headers and payloads) and acts accordingly as well as making sure that only allowed actions can be performed.

Some of the WAF capabilities that are crucial for API security are:

Known attack detection: Recognizing common attack strategies and blocking unauthorized access.
Malformed/anomalous request detection: Distinguishing legitimate API requests from those with malicious intent.
Virtual patching: Intelligently delivering security patches to early protect API endpoints until the root cause can be fixed.
Anti-bot automation: Identifying and blocking malicious bot traffic.
Audit logs: Producing audit information about matched rules and anomaly scores that can be aggregated to come up with actions.

Any system that receives traffic (internal or external) is a target for attacks and any system that is target for attacks can be protected by a WAF, from websites, blogs, government portals, e-commerces, forums. Some of the attacks categories a WAF can protect you against of is:

SQL Injection (SQLi): malicious traffic could manage to inject strings directly into SQL queries to perform undesired actions e.g. retrieve users data.
Cross Site Scripting (XSS): attacker injects malicious executable scripts into the code of a trusted application or website
Local/Remote File Inclusion: attacker includes local/remote files on the server to later execute them e.g. to expose server data.
Code Injection: attacker injects code into the application execution through a vulnerability e.g. to expose environment credentials in the output.
Session Fixation: permits an attacker to hijack a valid user session
Bot Detection: the process of identifying and distinguishing between human users and automated bots.
Metadata/Error Leakages: leaks server or implementation metadata or internal errors to the attacker e.g. to exploit known vulnerabilities.

In a multilayer security approach, a WAF sits in the first line, protecting our systems from traffic attacks, even before authentication or authorization as those could also be compromised by a footprint attack.

PCI DSS 4.0 has WAFs as a hard requirement

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard used to handle credit cards from major card brands. The requirements are specifically designed to protect against security breaches.

While merchants, e-commerce businesses, retailers, and financial institutions are common entities that must comply with PCI DSS, other industries and service providers also fall under its scope. For instance, healthcare organizations, hospitality businesses and in general any internet site that handle card payments for bookings and services must comply with PCI DSS.

Even an organization that does not process cardholder data could follow the PCI Standard to implement a robust cybersecurity program for any of its important data and gain the confidence of its customers.

In version 4.0 (deadline: March 2025) WAF takes a fundamental role. Requirement 6.4.2 [4] explicitly requires affected businesses to "Deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks" with compliance to at least the following criteria:

Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.
Actively running and up to date as applicable.
Generating audit logs.
Configured to either block web-based attacks or generate an alert that is immediately investigated.

WAFs targeting deeper protection

While originally WAFs were created and designed to protect API gateways as a first line of defense from outer traffic (so called north-south), strategies like zero-trust tell us that we should be protecting the system components as if the attacker is already inside of the network.

Hence in the same way we leverage a WAF in the API gateway we should be protecting the individual components from the internal traffic (so called east-west) with a WAF using a refined set of configurations and more symbiotic deployments where WAF is in the ingestion path of the component e.g. in the sidecar as part of a service mesh.

This is specifically important when it comes to lift and shift. Legacy systems being onboard in the cloud, also onboards all its vulnerabilities. Sometimes patching these systems is not an option because the code is too old, it lacks tests or requires risky upgrades while being critical. A WAF can help to protect them in the cloud without the need of doing changes into its code but instead rolling out a reverse proxy in front e.g. as a sidecar intercepting all the incoming traffic looking for exploits.

WAFs as part of the development workflow

With the proliferation of microservices, macroservices, lift and shift and lambdas, teams became more independent in a fast changing architecture which means that security teams can roll out general purpose organization-wide policies but it is the individual development team’s responsibility to compliment the security measures with curated WAF rules more related to their components and its specific risks.

This is a shift in the security mindset which moved from an afterthought and only delegated to security teams into a shared responsibility between development and security teams. A cloud native WAF promotes the so-called “shift-left” which is the practice of moving security, testing, quality, and performance evaluation early in the development process and making development teams accountable for that.

WAF unblocking your security pipeline

In December 9th 2021 a new vulnerability was disclosed in the super popular Apache log4j library, affecting an estimated 10 percent of all digital assets at time of discovery [5], allowing remote code execution (RCE) on underlying servers that run vulnerable applications. The next day, Log4j 2.15.0 was released and security teams were urged to install the latest version. In the next seven days two more vulnerabilities were disclosed and by January 4th, US Federal Trade Commission told companies to patch Log4j vulnerability threatening legal actions.

Two years later, more than 1 in 3 applications using Log4j currently run vulnerable versions of this library [6]. Research found that, in general, once developers are alerted to a vulnerable library through a scan, 50 percent of vulnerabilities are fixed in 89 days overall, in 65 days for high severity vulnerabilities and in 107 days for medium severity vulnerabilities.

These numbers tell us that patching vulnerabilities does not occur as frequently and quickly as one might expect, however it is a negligence to leave systems vulnerable and hence WAF features like Virtual Patching [7] can chime in to protect those unpatched systems.

Virtual patching is a method of protecting new vulnerabilities in the short-term to keep hackers away from breaching systems until they can be patched in code. A newly discovered CVE in OSS triggers several processes both in the OSS code as well as proprietary code and a patch landing into users’ systems requires several other processes leaving the system vulnerable during that time unless a virtual patch has been applied.

Conclusion

WAFs play a critical role in API security, serving as an essential component of a multi-layered defense strategy. By detecting and mitigating a wide range of threats in real-time, WAFs help safeguard APIs, protect business-critical sensitive data, and ensure the integrity of online services.

WAF not only takes part of the operational stage of the systems bringing protection and compliance, it brings more benefits across the entire security strategy across the engineering teams that will translate into customer trust and good reputation.