A key approach to moving security to the left is to move perimeter-focused security solutions down the stack by placing them in front of services and other infrastructure components, such as containers and orchestration systems. containers or API management systems and gateways.

While this allows for more granular security, it’s not a free lunch for developers. Just saying “The WAF will stop it” reverses the whole thought and purpose of the left turn. Instead, developers need to stop viewing web application firewalls (WAFs) as prophylaxis, and instead view WAFs as a crucial part of their secure coding testing process. Here’s how they can achieve it.

The explosion of WAFs and cloud-native software

While many enterprises are still deploying WAF appliances, the fastest growing segment of this market is WAF software that runs in the cloud. With the rise of cloud-native architectures and ephemeral infrastructure, more organizations are placing WAFs deeper into their application stacks, just ahead of microservices. Some even use WAFs for internal protection to implement robust zero-trust frameworks. So the new reality is that developers are far more likely to come into close contact with WAFs today than at any time in the past. That said, microservice-level WAFs aren’t foolproof.

Before deploying the WAF: secure coding is essential

To begin with, developers should build applications assuming that all security checks can and will fail. This is important because it encourages them to create secure apps by default. Secure coding means using basic design principles – like minifying code to obfuscate code – while ensuring that all variables and calls are checked against the OWASP Top 10
vulnerability list. There are dozens of ways attackers can exploit poorly written code, including SQL injection, cross-site scripting, broken access controls, and file upload vulnerabilities.

A key part of this effort is making sure developers run linters and format checkers against all code. Usually, you’ll want developers to run code through software composition analysis (SCA) to identify risky dependencies and libraries that need updates. A secure coding process and mindset is more critical now, as cloud-native microservices have turned security on its head.

At this point, the Application Security or DevSecOps teams run the code against some sort of simulation and add the WAF. For many developers, that’s the end of the story. They assume, “We’ve deployed a WAF. We’re safe now.” They are wrong. Increasingly, app developers are offering microservices, linked through APIs. Developers “own” their microservices and APIs and are responsible for security. Microservices and APIs can have very specific rules and optimizations that can impact WAF behaviors and policies. Every application is different and many unique APIs emerge.

For microservices, developers tend to ship code quickly and iterate faster on microservices because these smaller applications are loosely coupled and don’t impact other applications. This allows for greater agility but also a greater security risk if changes are not executed through the same tedious security process seen at application launch.

Learn to think like a WAF operator

Developers should always ask themselves before shipping code: “How will this affect my WAF coverage and security posture?” This question is good because it teaches them to think about how WAFs work and don’t work – in other words, threat modeling.

Threat modeling is essential because there are known ways for attackers to circumvent WAFs or exploit weaknesses in WAFs. For example, by default, Kubernetes exposes APIs for services and connections. Locking down Kubernetes APIs without spoiling functionality is notoriously difficult, especially if you regularly modify applications and service calls within applications. Recently, Shadowserver Foundation calculated that 84% of Kubernetes API servers left themselves exposed to detection on the public internet.

Understanding a WAF is a key precursor to threat modeling and, by extension, thinking like a firewall operator. Some understanding of the WAF is tacit knowledge. For example, tuning a WAF to limit false positives and false negatives to an acceptable level is still difficult. Developers looking to move left can rely on experienced WAF operators to learn the tuning process and, in turn, better understand how the WAF reacts to real traffic. Today, some organizations are also deploying machine learning to help developers easily tune their WAFs by making rule and policy suggestions based on unsupervised learning across multiple WAFs.

Better understanding of WAF leads to more secure code

Even better, a good understanding of WAF also translates into more secure coding. Developers who intimately understand WAFs — and have hands-on experience tuning them — benefit from hard-to-teach tacit knowledge and experience that goes beyond the Open Web Application Security Project (OWASP} checklists. Another best practice is, in a safe environment, for developers to work alongside red team members to see how a smart attacker could compromise their apps and bypass default WAF settings.

The bottom line is simple: Developers, take the time to know your WAF and learn its weaknesses. WAF wisdom will help you write secure code now and prevent your applications from being hacked in the future.