Getting started
Domains & Origins

Domains & Origins
Request settings
Cache settings
Custom VCL
Image optimization

Access Control Lists
Monitoring and testing
Securing communications
Security measures
Web Application Firewall

Logging endpoints
Non-Fastly services

Streaming logs
Debugging techniques
Common errors

Account info
Account management
User access and control


    Web Application Firewall (WAF)

      Last updated September 24, 2019

    Fastly offers a Web Application Firewall (WAF) security product that allows you to detect malicious request traffic and log or log and block that traffic before it reaches your web application. The Fastly WAF provides rules that detect and block potential attacks. The rules are collected into a policy and deployed within your Fastly service at the edge. To get started, email our sales team for product information.

    How the Fastly WAF works

    The Fastly WAF is designed to protect production web applications running over HTTP or HTTPS against known vulnerabilities and common attacks such as cross-site scripting (XSS) and SQL injection. The Fastly WAF can provide a layer of protection logically positioned at the client edge of your distributed application to detect and block malicious activity from exploiting vulnerabilities in web applications and APIs.

    Image showing attacker blocked by the Fastly WAF

    Like traditional network firewall appliances, Fastly WAF uses predetermined security rules to monitor and control incoming traffic to your web application. A network firewall works at the IP level and often blocks IP addresses from untrusted networks, preventing them from gaining access to a private network. Unlike firewalls at the network or transport layer level, the Fastly WAF works by analyzing web traffic primarily at the HTTP application layer. It reads all HTTP(S) headers and the post body of the HTTP(S) requests that it inspects and runs them through a rule set selected for your service environment.

    Fastly provides a default WAF rule set to which you can add additional rule sets to help protect against application-specific attacks. Once the Fastly WAF is enabled for a version of your service, you can change the status of any individual rule to logging, blocking, or disabled mode. Rule changes are versionless and become effective immediately.

    Enabling the Fastly WAF

    Enabling Fastly WAF doesn't require modifications to your web application or origin servers. Contact our sales team to get started.

    Refining the default WAF policy once it's enabled

    Once you purchase the Fastly WAF, our customer support team will enable it with the default WAF policy for any service you've provided a service ID for. They will then work closely with you on additional configuration refinements, including:

    You can then begin monitoring logs to determine which requests to your origin are legitimate and which you should consider blocking to protect your origin.

    Setting up a logging endpoint

    To begin monitoring requests for potential malicious activity, set up remote logging so you can log WAF variables. You can use an existing logging endpoint or add a new endpoint specially for Fastly WAF. You'll use the information provided in the logs to monitor WAF events.

    Selecting rule sets

    Fastly provides a default WAF rule set based on Trustwave ModSecurity Rules and the OWASP Top Ten. The default rule set is designed to help you monitor web application traffic for a wide range of common attacks.

    Fastly adds a default prefetch condition (!req.backend.is_shield) for the WAF policy. This ensures that the Fastly WAF inspects traffic to the origin and accounts for whether or not a service has shielding configured.

    You can modify the prefetch condition. For example, you could update the prefetch statement to run the WAF rule set on origin traffic and requests from IP addresses that aren't allowlisted:

    curl -v -X PUT<your Fastly service ID>/version/<version_id>/condition/Waf_Prefetch -H "Fastly-Key: FASTLY_API_TOKEN" -H "Content-Type: application/json" -d '{"statement":"!req.backend.is_shield && !(client.ip ~ allowlist)"}' -H "Accept: application/json"

    Fastly can add additional rule sets for specific applications or technologies (e.g., WordPress, Drupal, PHP, .Net). Keep in mind that adding additional rule sets can increase latency for requests being evaluated against the published WAF policy.

    Once you've selected rule sets, Fastly will maintain rules sourced by Fastly to keep them current. However, you'll need to notify us if you modify the applications or technologies that are present at the origin.

    Customizing the response

    Fastly's customer support team creates a custom response and assigns an HTTP status code for all requests that Fastly WAF blocks. If you've configured Fastly WAF to block requests, that response will be served directly from the cache when a request matches a rule. If you would like to customize the response, use the web interface to change the following:

    Monitoring the Fastly WAF

    You can use the Fastly WAF dashboard to monitor the Fastly WAF deployed within your Fastly service.

    Disabling Fastly WAF for your service

    Contact our customer support team at to disable the Fastly WAF for your service.


    All WAF products that exist today have several limitations:

    LA limitations

    The Fastly WAF is part of a limited availability release and it has the following limitations:

    Security products note

    No security product, such as a WAF or DDoS mitigation product, including those security services offered by Fastly, will detect or prevent all possible attacks or threats. Subscribers should maintain appropriate security controls on all web applications and origins, and the use of Fastly's security products do not relieve subscribers of this obligation. Subscribers should test and validate the effectiveness of Fastly's security services to the extent possible prior to deploying these services in production, and continuously monitor their performance and adjust these services as appropriate to address changes in the Subscriber's web applications, origin services, and configurations of the other aspects of the Subscriber's Fastly services.

    Back to Top