---
title: Understanding Edge Services Web Application Firewall (WAF)
description: Learn how to protect your web applications with Scaleway Edge Services Web Application Firewall (WAF). Discover the principles, paranoia levels, and limitations of WAF, and find out how to define exclusions for optimal security and performance.
tags: edge-services web-application-firewall waf paranoia-levels exclusions
dates:
  validation: 2026-06-09
  creation: 2025-03-03
---
import image from './assets/scaleway-edge-services-waf-diag.webp'
import image2 from './assets/scaleway-edge-services-pipeline-diag.webp'


You can choose to enable the **W**eb **A**pplication **F**irewall (WAF) feature on your Edge Services pipeline, for added protection. This documentation page gives a detailed overview of WAF, and the different settings, modes and functionalities available.

## WAF overview

When enabled, WAF protects your backend from potential threats.

It does so by evaluating each request to your backend, to determine whether it is potentially malicious. Four different rulesets can be used to evaluate requests, each more aggressive than the last. The ruleset to use is determined by the **paranoia level** set by the user.

For requests judged to be malicious, WAF can either block them from passing to your backend (as shown in the diagram below), or simply log them but allow them to pass, depending on the settings you choose.

You can set **exclusions**, so that certain requests are not evaluated by WAF and are allowed to pass directly to your backend. Exclusion filters are based on the request path and/or HTTP request type.

<Lightbox image={image} alt="A diagram shows how Edge Services WAF deals with three different types of HTTP request. A request meeting the criteria for WAF exclusion is passed directly to the backend. A benign request is first checked by the WAF rules, then allowed to pass to the backend. A malicious request is checked by the rules, and blocked from passing to the backend." />

## WAF in an Edge Services pipeline

In an Edge Services pipeline, WAF sits before the backend stage. This means that WAF only protects your backend, it does not protect or filter requests toward the cache.

<Lightbox image={image2} alt="A diagram shows the elements and workflow of an Edge Services pipeline. The user connects to the customizable Edge Services endpoint (with its SSL/TLS certificate), which fetches content from the Edge Services cache, which itself fetches content to cache from a backend. A Web Application Firewall sits between the cache and backend, protecting the backend from threats." />

If you have both WAF and cache enabled, requests that can be served by the cache will not go through WAF. Only requests that cannot be served by the cache will be filtered by WAF, and allowed to pass to the backend or not, depending on your WAF configuration.

## WAF ruleset and paranoia levels

Scaleway Edge Services WAF uses the [OWASP **C**ore **R**ule **S**et (CRS)](https://coreruleset.org/). This is an industry standard, open source ruleset for WAF, which protects against multiple categories of attack such as SQL injection and cross-site scripting. Full details are available in the [OWASP CRS documentation](https://coreruleset.org/docs/).

**Paranoia level settings** are an integral part of the core ruleset. They dictate how aggressive the ruleset should be when judging whether a given request is malicious or not. The paranoia level is rated from 1 to 4, which each being more aggressive and more sensitive to potential threats than the last.

The four levels are:

- **1 - Minimal protection**: Basic security, suitable for environments with low sensitivity, prioritizing minimal false alerts.
- **2 - Moderate protection**: Solid protection for environments dealing with real-world customer data.
- **3 - Strong protection**: Banking-standard security, prioritizing safety but prone to frequent false alerts.
- **4 - Maximum protection**: Hyper-paranoid rules, fit for protecting the most critical and sensitive assets.

The higher the paranoia level, the more likely you are to have **false positives**. This is when WAF classes a request as malicious, when in fact it is not. 

- At level 1, the ruleset is unlikely to trigger false positives, however it is also more likely to miss threats and aggressions and classify them as benign.

- At level 4, the ruleset is so aggressive that it detects almost every possible attack, however it is also highly likely to trigger a significant number of false positives whereby a lot of legitimate traffic will be classed as malicious.

|  | Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|---|
| Number of threats detected | Lowest | Moderately Low | Moderately High | Highest |
| Number of false positives | Lowest | Moderately Low | Moderately High | Highest |

Choosing a paranoia level therefore means trading off **how hard it is for an attacker to go undetected** against **how much legitimate traffic is incorrectly classified as malicious**. This depends on your use case, and the sensitivity of the application and assets being protected by WAF.

- Anyone running an HTTP server on the internet could benefit from level 1 protection.
- If real user data is involved, consider level 2.
- For online banking, consider level 3
- For crown-jewel level assets, consider level 4.

Find out more about paranoia levels in the [official OWASP CRS documentation](https://coreruleset.org/docs/2-how-crs-works/2-2-paranoia_levels/).

Read on to find out how you can use **exclusions** to mitigate the effect of some false positives.

## WAF exclusions

WAF **exclusions** are filters that allow matching requests (based on **path** and/or **HTTP request type**) to bypass WAF entirely.

You can set up to 100 exclusions after enabling WAF on a given pipeline.

- **Path filter**: Define a regular expression to filter for in request paths, e.g. `/api/v1/.*`
- **HTTP request filter**: Define one or more HTTP request types to filter requests for, e.g. `GET`, `DELETE`, `POST` etc.

Each exclusion can consist of:

- A path filter only, OR
- An HTTP request filter only (which itself can filter for multiple request types on an `ANY` basis), OR
- One path filter and one HTTP request filter. In this case, only requests matching **both** filters will be considered to meet the criteria for exclusion.

## WAF limitations

- WAF only analyzes the first 16 384 bytes of the body of HTTP/S requests. 
- WAF protects your backend only, and not your cache.
- You can add a maximum of 100 WAF exclusions.
- You cannot currently specify exclusions at the individual rule level. Requests matching exclusion filters bypass WAF entirely.