How the Edge WAF works

The Edge WAF hosts the Next-Gen WAF on Fastly’s Edge Cloud platform via our global network of POPs and integrates with our caching layer. Since security processing happens at the edge, the Edge WAF inspects all traffic before it enters your origin infrastructure and blocks attacks close to where they originated. The Edge WAF is able to process a request within a few milliseconds.

North-south traffic

In an Edge WAF deployment, the Fastly platform, which includes the Edge WAF, sits between the client and your origin. Positioned at the perimeter of your network, the Edge WAF inspects and protects your web application from north-south traffic by analyzing incoming requests as well as response headers and status codes. In this way, the Edge WAF acts like a fence around your house, keeping unwanted visitors off your property before they even have a chance to approach your door.

Request flow

When a web client makes a request to a web application protected by your Edge WAF deployment, the request is first sent to your CDN or Compute service. Your service checks if the requested response objects are cached. If the objects are in the cache, request inspection is skipped and your service responds with the cached objects. Request inspection is skipped because the cached objects were previously inspected when they were originally pulled from the origin.

If the objects aren’t in the cache, Fastly creates an instance of the Edge WAF to inspect the request. Each Edge WAF instance (also known as an edge security service) is a temporary Compute service that handles WAF functionality for one request. It will never process more than one request.

Upon creation of the Edge WAF instance, the cloud engine sends the Edge WAF your WAF configurations (e.g., rules) and unique data (e.g., list of flagged IP addresses). The Edge WAF uses this information to determine what should happen to the request (e.g., allow or block) and to tag the request with the appropriate request signals.

If the request appears malicious, the Edge WAF blocks the request from accessing your origin, generates a response using the blocking response code that is configured for your site (workspace), and sends the response to your service. Your service then forwards the response to the web client that initiated the request.

If the request is legitimate, the Edge WAF forwards the request to your origin. The origin generates a response and sends the response to the Edge WAF. The Edge WAF performs any additional WAF functions and then forwards the response to your service. Your service executes any final actions that you’ve configured and then serves the response to the web client that initiated the request.

As soon as the request has been fully processed, the Edge WAF sends request and response data to the cloud engine. Finally, the Edge WAF instance shuts down and terminates permanently.

Threshold counting

An Edge WAF deployment uses both local and global counting mechanisms to track the number of signals per client and to determine when a client exceeds the threshold of a site alert (also known as workspace alert) or advanced rate limiting rule.

Located at the Fastly POP-level, the local counting mechanism tracks signals over a 60 second window during the interval set by the site alert (workspace alert) or the advanced rate limiting rule. The total signal count for each window is added to the next window for the duration of the interval. If the count from the last completed window causes the total signal count for a client to exceed the threshold of a site alert (workspace alert) or an advanced rate limiting rule, subsequent requests from that client are handled per the direction of the site alert (workspace alert) or the advanced rate limiting rule that was violated. As the local counting mechanism is distributed across a number of cache nodes in a single POP, there may be a slight synchronization time delay.

Located in our cloud engine, the global counting mechanism aggregates the signal count from our entire POP network. The cloud engine then forwards the aggregated count to the Edge WAF deployment, which takes approximately one to two minutes.

Health check

The Edge WAF includes a health check feature that monitors the health of the Edge WAF. When the Edge WAF is unhealthy, requests are allowed to proceed to the origin without being inspected. The health check does not monitor the status of your origin.

The health check works by sending a periodic probe every 15 seconds and checking for the HTTP status code 200 as an expected response. Should a check indicate that the Edge WAF is unhealthy, all security processing is skipped until the Edge WAF becomes healthy again. It may take up to 60 seconds for all security processing to be skipped.

The Edge WAF is modeled as an origin using the backend type. The health check lives inside the edge_security function and uses the backend.health property to check the status of the Edge WAF.

Maintenance

Fastly manages all Edge WAF deployments, which includes regularly updating our detection engine (e.g., SQL injection detection improvements), releasing virtual patches for Common Vulnerabilities and Exposures (CVE), and scaling the WAF to handle variable traffic volumes.

If you enabled the Edge WAF using the Fastly control panel, there are no maintenance tasks that you need to perform. If you enabled the Edge WAF using the Next-Gen WAF API, you may need to perform occasional maintenance tasks, such as:

• updating the VCL version of your deployment when Fastly releases a new Next-Gen WAF feature that you want to use.
• synchronizing your origins if you don’t have dynamic backends enabled and you changed your origins in the Fastly control panel.

Data integrity and security

Traffic from Edge WAF deployments are never mixed. Since Fastly creates a temporary Edge WAF instance for each request that requires inspection, each request is processed in isolation. For example, if both Company A and B have an Edge WAF deployment and you make a request to Company A’s web application, you won’t get an accidental response from Company B’s web application because your request never came in contact with another request.

Request isolation also protects your web application from malicious actors. In the unlikely event a hacker gains access to an Edge WAF instance and leaves behind a backdoor, the hacker won’t be able to access or manipulate data beyond the single request assigned to that Edge WAF instance. The hacker can’t use the backdoor they created to access anything else because the Edge WAF instance terminates permanently after the request is processed, which means that the backdoor ceases to exist.