The primary function of a WAF is to protect applications that communicate over HTTP, including websites, API endpoints, and serverless functions.

WAFs are the first layer of defense for the web. They can detect and block known and unknown attacks, lock down insecure systems, prevent data leaks, control access to URLs and ports, and mitigate the risk of inadequately configured servers.

A WAF provides all the benefits of a regular network firewall and more. It can detect advanced attacks such as the ones described in the OWASP Top 10 Threats list, enforce security policies, and ensure SSL security mechanisms

While threat prevention is the primary use case for a WAF, it’s not by any means the only one. Any website that processes or stores credit card data must comply with the Payment Card Industry Data Security Standard (PCI-DSS). Non-compliance can have grave consequences; breaches or credit card frauds in uncertified systems are heavily fined.

PCI-DSS mandates that websites must pass a security assessment (Requirement 6.6). The requirement can be fulfilled either by a code review—which can be expensive—or by setting up a WAF. Adopting a WAF can be the quickest and most efficient way to comply with regulatory requirements.

Credit card companies are not the only ones demanding increased security levels; other regulatory standards such as HIPPA and SOX have similar requirements.

Bots are taking over. A third way in which WAFs can help us is by controlling their access to our systems.

On the Internet, there are good bots and bad bots. The good ones are fundamental for keeping things working. The bad ones will try to scrape content from websites, send spam, steal information, install malware, abuse APIs, brute force passwords, or initiate a DDoS attack.

Bots can cause damage by amplifying the effect of exploits or by over-utilizing resources and causing unexpected costs. NixCraft learned this the hard way when they started suffering from spambots. Fortunately, implementing StackPath’s WAF nipped the problem in the bud. StackPath’s WAF can block repeated access from bots with fine-grained rate limits and CAPTCHA rules.

No code is perfect. Despite the best efforts to secure an application, there will always be some chance of vulnerabilities sneaking into production. When that happens, it can take some time until a solution is found and a patch is released.

The situation is even worse when a third party owns the code. Some vendors can take several days or weeks to release a patch. For instance, WordPress, the most popular CMS platform in the world (and the most hacked), releases security patches on a monthly schedule. Some of its plugins can have even more infrequent release schedules.

Unmaintained code is another problem altogether. When the source is no longer available, there is no way to patch it. In such cases where there is no suitable alternative, a WAF can be the only way of securing and locking down these systems.

Administrators and security teams have to keep track of traffic in real-time to detect attacks and act accordingly. On distributed systems, this is difficult because logs are scattered among many heterogeneous interfaces. Oftentimes intrusions are only detected hours or days after taking place.

A WAF acts as a central point of logging and metrics collection, with a particular focus on security. Administrators can monitor traffic, detect attacks in real-time, and take appropriate actions. WAF logs are also vital for diagnosing and assessing previous attack attempts.

Since WAFs can inspect and filter HTTP packets, organizations can set up rules to allow or block connections based on their content. For example, a WAF can prevent certain types of files or content types from passing through the wires.

WAFs can be configured to serve differentiated content based on the originating country, too. For example, to serve geographically-dependent content, you can implement regional locking or comply with export restrictions.