IMPORTANT: As of July 13, 2020, Fastly's original WAF offering became a legacy product. It will continue to be supported for all existing users. As alternatives, Signal Sciences Cloud WAF or Signal Sciences Next-Gen WAF both offer proactive monitoring of and protection against suspicious and anomalous web traffic directed at your applications and origin servers. Each can be controlled via web interface or APIs. Contact email@example.com or your Fastly account team to evaluate or move to the Signal Sciences WAF options.
WAF 2020 filters requests through a set of security rules that match patterns known to be associated with malicious traffic. There are three types of rules:
- Scoring rules: Rules which, when matched, do not immediately flag the request, but will contribute a score to a category and an overall total. Rules based on the OWASP core ruleset are scoring rules, as are some Fastly rules.
- Strict rules: Strict rules are those which will, when matched, immediately flag a request. Most Fastly rules and all Trustwave rules are strict.
- Threshold rules: Rules which flag a request if a scoring category or the total anomaly score exceeds a configured threshold. Threshold rules work in conjunction with scoring rules, and do not match on characteristics of the request, but instead match on the current value of an anomaly score.
When a request is flagged by the WAF, it may be blocked and return an error response to the client, or may allow the request to proceed as normal, depending on a service's WAF configuration. Running a WAF in 'logging' mode is a common practice when it is first enabled to avoid false positives from blocking an unacceptable amount of legitimate traffic. See tuning your WAF in the WAF product documentation for more details.
waf_debug_log subroutine is invoked once for each rule matched by the WAF engine, providing the opportunity to sample the values of WAF variables after each rule is processed.
waf.-prefixed variables are read-write in VCL, and have no special meaning to the Fastly platform outside of the WAF product. While it is possible for these variables to be updated by custom VCL code, care should be taken to avoid conflicting with the use of these variables by the WAF. The variables
waf.executed, all of type
BOOL, are write-once: for each request, they start out set to
false and may be
true, but once set to
true any further attempt to change the value will be ineffective.