The Web Application Firewall (or WAF) is a firewall that operates at the Web (HTTP) layer of your application. It blocks common classes of errors that exist in web-based applications. It is useful to prevent zero-day attacks, to give you more time to apply patches, and as a general Defense-In-Depth strategy.
The main protection it gives is generic for:
- Cross-Site Scripting (XSS)
- SQL Injection
- Web Session Hijacking
All while not changing the application source code.
If you operate a web application (you operate the webserver), you should use a web application firewall if:
- The application is not read-only (it accepts user input)
- It accepts or displays 3rd-party content
- It accepts or displays user-generated content
- It has an API
- The user can authenticate
- The webserver is anything other than a simple Nginx or Apache server with static content (for example, you run Java or ASP or PHP)
- The webserver has access to any internal content such as a database or shared filesystem
Your Web Application Firewall should always be in use. It should have rules calibrated to each path and method call (for example, only authenticated users can POST to /api/updates). Setting up these rules can be complex and requires knowledge of how the application functions. Do not just accept the defaults and hope! If you have input to the design of the Web Application, follow these rules to simplify securing it:
- Avoid using self-modifying CSS and HTML (don’t require unsafe eval or inline)
- Have a common location in the API schema for the user-id
- Compile templates ahead of time
- Avoid using 3rd-party libraries and content hosted by external sites
- If you do use 3rd-party hosted, use subresource integrity
An unexpected and positive side-effect of the web application firewall is simplified and enriched reporting into your security event logging.
If you operate a web application, the web application firewall gives you peace of mind, simply, with low cost. It doesn’t replace writing secure applications, it augments.