---
title: "Configuring the OVHcloud Web Application Firewall"
description: "Find out how to set up the OVHcloud Web Application Firewall to inspect, filter, and block malicious HTTP/HTTPS traffic before it reaches your backend"
url: https://docs.ovhcloud.com/pl/guides/network/ovhcloud-waf/configure-waf
lang: pl
lastUpdated: 2026-07-23
---
# Configuring the OVHcloud Web Application Firewall
:::warning
**Important**: The OVHcloud Web Application Firewall is currently in **closed alpha**. The feature set, limits, and WAF Console described in this guide may change before general availability. Access is granted on a case-by-case basis via the [OVHcloud Labs](https://labs.ovhcloud.com/en/owaf/) page.
:::
## Objective
This guide presents the capabilities and walks you through the end-to-end setup of the OVHcloud Web Application Firewall (OWAF) during the alpha programme, from requesting access to tuning protection and monitoring live traffic in the WAF Console. It also describes the most common configuration scenarios and best practices.
## Requirements
- An active OVHcloud account
- Approved access to the OVHcloud Web Application Firewall alpha programme (see [Step 1: Join the alpha](#step-1-join-the-alpha))
- An **account access token** issued by OVHcloud during onboarding, used to sign in to the WAF Console
- A reachable **backend (origin) server** addressable over HTTP or HTTPS that will receive proxied traffic
- The ability to point a domain (DNS `A` record) at the WAF instance and to allow the WAF egress IPs on your origin's firewall
- A modern browser — Chrome, Firefox, Edge, or Safari (latest two versions)
- Knowledge of HTTP/HTTPS traffic, web application security concepts, and the OWASP Core Rule Set
## Introduction to the OVHcloud Web Application Firewall
The OWAF is a high-performance Web Application Firewall that inspects, filters, and blocks malicious HTTP/HTTPS traffic before it reaches your backend applications, with no code changes required on the protected service. Its rules engine is based on the **OWASP Core Rule Set (CRS)**, covering common attack vectors such as SQL injection (SQLi), cross-site scripting (XSS), remote code execution (RCE), local file inclusion (LFI), server-side template injection (SSTI), and scanner detection. The WAF is operated through the **WAF Console**, a web application for real-time configuration and monitoring.
Client traffic is sent to the WAF instance on port `443` (HTTPS), where each request is inspected against the active rule set and scored against the anomaly threshold. Requests that pass the inspection are forwarded to the backend defined as the **Origin URL**; requests that exceed the threshold in **Blocking** mode are rejected with a `403 Forbidden` response. Operators configure the engine and view live metrics through the WAF Console, which is fully independent from the data path.
For a more detailed overview of the OWAF, see the [OVHcloud Labs page](https://labs.ovhcloud.com/en/owaf/).
## Use cases
The following use cases will be supported at general availability:
| Use case | Description |
| :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Filter malicious traffic** | Automatically block SQL injections, XSS attacks, unauthorized access attempts, and exploits of known vulnerabilities before they reach your servers. |
| **Take control of bot traffic** | Tell legitimate bots (search engines, partners) apart from harmful ones (scrapers, vulnerability scanners) and apply the right policy to each. |
| **Rate-limit by client** | Protect your APIs and sensitive forms against abuse by capping the number of requests per IP, per user, or per endpoint. |
| **Prevent account takeover** | Detect and stop automated login attempts, credential stuffing, and brute-force attacks on your login pages. |
| **Meet compliance obligations** | Demonstrate the deployment of a WAF to your PCI-DSS, ISO 27001, NIS2, or DORA auditors with a complete, exportable audit log. |
| **Emergency virtual patching** | A new CVE announced on a Friday evening? Push an OWAF rule to block exploitation, without waiting for the application patch. |
## Service capabilities and limits
Before configuring the OWAF, be aware of the following capabilities and constraints.
### What the OWAF can do
- **Full request inspection** of inbound HTTP/HTTPS traffic, including headers, body, URI, cookies, and query parameters.
- **OWASP Core Rule Set coverage** with managed rules detecting SQLi, XSS, RCE, LFI, SSTI, scanner detection, and other common attack categories.
- **Per-rule control** from the Rules tab — browse the active rule set, filter by category or type, and enable or disable individual rules.
- **IP allow and block lists** managed from the Advanced tab, enforced as custom rules evaluated before the managed rule set.
- **Three operating modes** — **Blocking** (matched requests receive a `403 Forbidden`), **Detection** (rules are evaluated and logged but traffic is allowed through), and **Disabled** (traffic is forwarded without inspection).
- **Anomaly scoring** that aggregates the scores of all matching rules and blocks the request only when the total reaches the configured threshold, which helps reduce false positives.
- **Paranoia Levels 1 to 4** to tune how aggressively the engine flags suspicious traffic.
- **Live security-event logs** in the Logs tab and a real-time traffic dashboard in the Metrics tab.
- **Immediate updates** — configuration changes are applied immediately, without a restart.
### Current limits (alpha)
| Limit | Value |
| :------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Region | The OWAF is available only in the **eu-west-gra** (Gravelines) region. |
| Custom-rule authoring | Not available in the WAF Console (the managed rule set can be enabled/disabled per rule; client IP lists are managed from the Advanced tab). |
| Advanced modules | Bot management, Rate limiting, Threat intelligence, Fraud prevention, API security, and Event forwarding (SIEM) are planned but not yet available. |
| High availability | Single node (HA mode planned for general availability). |
| Customer SSL certificate | Not yet supported (SSL certificates are fully managed by OVHcloud in the alpha phase). |
| Programmatic configuration | An OVHcloud API or Terraform resource is not part of the alpha — all configuration is performed in the WAF Console. |
:::info
These limits apply to the **alpha** release and will evolve before general availability. Your feedback during the alpha is essential — report issues, false positives, or feature requests directly to your OVHcloud contact.
:::
## Instructions
### Step 1: Join the alpha
The OWAF is currently available as a closed alpha. To request access, fill in the form on the [OVHcloud Labs](https://labs.ovhcloud.com/en/owaf/) page with the following information:
- Your OVHcloud NIC handle (customer identifier)
- A brief description of your use case
- The URL of the application you want to protect
- The domain name that points to the OWAF
Once your request is approved, the OVHcloud team will create your WAF configuration and send you an **account access token** to sign in to the console.
:::info
**Important**: During the alpha phase, OVHcloud cannot commit to a specific delivery time. Onboarding can take up to a few days.
:::
### Step 2: Sign in to the WAF Console
Sign in with your **account access token** to reach your WAF configuration.
1. Open your browser and go to the [WAF Console](https://labs.waf.ovh.net/).
2. On the **Control Plane Access** card, paste your account access token in the **Access token** field (a leading `Bearer` prefix is stripped automatically).
3. Click Sign In.
You are redirected to the **My Web Application Firewall** page, which shows your WAF configuration.
:::info
Your token is stored locally in your browser so you stay signed in. Clicking `Sign out
` clears it and returns you to the sign-in page.
:::
### Step 3: Open your WAF configuration
The **My Web Application Firewall** page shows your WAF configuration and a summary of its live state.
The summary shows:
| Field | Description |
| :--------------- | :----------------------------------------------------------------------------------------------------------------- |
| **Name** | The configuration display name, with its ingress IP shown beneath. |
| **Mode** | Current operating mode: `Blocking`, `Detection`, or `Disabled`. |
| **Paranoia** | The active Paranoia Level (`PL1` to `PL4`). |
| **Threshold** | The anomaly threshold at which a request is blocked. |
| **Active rules** | The number of currently active rules. |
| **Origin** | The backend (origin) URL that receives clean traffic. |
| **Status** | `Ready` (healthy), `Degraded` (reachable but unhealthy), or `Unreachable` (the configuration could not be loaded). |
Click your configuration to open its detail page.
The detail page organises the configuration into six tabs:
- General Information — see where the WAF sits and where it forwards traffic, so you can point your domain at it.
- Protection — control how aggressively the WAF blocks, and switch between Detection and Blocking.
- Rules — review the active rule set and turn individual rules on or off.
- Advanced — allow or block clients by IP.
- Logs — investigate the requests the WAF has blocked or detected.
- Metrics — monitor traffic volume, block rate, and where attacks come from.
### Step 4: Review the general information and wire up DNS
The `General Information
` tab shows where the WAF sits and where it forwards clean traffic. Use it to point your domain at the WAF and to allow the WAF's egress on your origin.
The **Configuration** card lists:
| Field | Description |
| :------------------ | :-------------------------------------------------------------------------------------------- |
| **Name** / **ID** | The display name and identifier of the configuration. |
| **Origin URL** | The backend server that receives clean traffic. |
| **Public hostname** | The public hostname assigned to the WAF instance. |
| **Ingress IP** | The public IP address clients reach the WAF on. Point your domain here. |
| **Egress IP** | The IP addresses the WAF connects to your origin from. Allow these on your origin's firewall. |
The **Traffic path** diagram illustrates the flow: **Client (Internet)** → **WAF** → **Origin**.
To route your domain through the WAF:
1. Log in to your DNS provider's management console (for example, the OVHcloud Control Panel, Cloudflare, or Route 53).
2. Locate the DNS zone for the domain you want to protect.
3. Create or update an `A` record pointing your domain (or subdomain) to the **Ingress IP** shown on the General Information tab:
| Field | Value |
| :--------- | :------------------------------------------------------------------------------- |
| **Type** | `A` |
| **Name** | The hostname you want to protect (for example, `www` or `@` for the apex domain) |
| **Target** | The **Ingress IP** shown in the WAF Console |
| **TTL** | `3600` (or your provider's default) |
4. On your origin server's firewall, allow inbound connections from the **Egress IP** addresses listed on the tab.
5. Save the DNS record and wait for propagation. You can verify with `dig +short your-domain.example.com`; the response must return the WAF ingress IP.
:::info
DNS propagation can take from a few minutes up to 24 hours depending on the TTL of any previous record. Wait until the new IP is returned globally before sending production traffic, as TLS certificate issuance relies on the domain resolving to the WAF instance.
:::
### Step 5: Set the protection profile
The `Protection
` tab controls how aggressively the WAF enforces the rule set. For a first deployment, start in **Detection**
mode to observe what would be blocked before enforcing anything.
1. Open the Protection tab.
2. Under **Enforcement mode**, click the card for the mode you want to apply:
| Mode | Behaviour |
| :---------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Detection | Monitors and logs attacks without blocking. Start here to see what would be caught, then switch on blocking. |
| Blocking | Enforces protection — a request is rejected with a `403` once its cumulative rule score crosses the anomaly threshold.
Recommended for production. |
| Disabled | Traffic passes through uninspected. Use only for debugging. |
3. Under **Paranoia level**, select the level from the dropdown (`PL1` to `PL4`):
| Level | Description |
| :------ | :--------------------------------------------------------------------------------------------------------------------------- |
| **PL1** | Only the most common and reliable attack patterns. Lowest false-positive rate.
Recommended for most deployments. |
| **PL2** | Broader detection coverage. May produce some false positives. |
| **PL3** | Aggressive detection. Expect more false positives.
Recommended for high-security applications. |
| **PL4** | Maximum detection. Will produce many false positives.
Suitable for security-critical environments with careful tuning. |
4. Optionally, adjust the **Anomaly threshold**. This is the score at which a request is blocked. Each matching rule adds its score (5 by default) to the request's total; if the total reaches or exceeds the threshold, the request is blocked. A lower value is stricter; a higher value is more permissive.
5. Click Apply changes.
The `Apply changes
` button is enabled only when your draft differs from the loaded configuration. Changes are applied immediately.
:::info
**How Paranoia Levels work**: each rule has an assigned Paranoia Level. Only rules at or below the global Paranoia Level are active. For example, at `PL1` only level 1 rules are active; at `PL3`, level 1, 2, and 3 rules are all active.
:::
### Step 6: Verify the setup
After Steps 4 and 5, validate that the WAF is processing traffic as expected:
1. From a client, send a normal request to your protected domain over HTTPS and confirm the response is served by your backend.
2. Send a known-malicious request, for example a path-traversal probe (`GET /.env`) or a basic SQL injection probe in a query parameter (`?id=1' OR '1'='1`).
3. Open the Logs tab and confirm the request appears as a security event. In Detection mode the malicious request is logged but allowed through; in Blocking mode it is rejected with a `403 Forbidden`.
4. Open the Metrics tab and confirm the **Total requests** and **Blocked** counters increase.
:::warning
During the alpha, do not rely on the OWAF as the sole protection layer for a production workload until general availability.
:::
## TLS management
TLS is **fully managed by OVHcloud**. You do not need to provision certificates, configure a reverse proxy, or handle renewals.
- Send your traffic to the WAF instance over **HTTPS on port `443`**. Plain HTTP is redirected to HTTPS automatically.
- Certificates are automatically issued and renewed for the WAF's public hostname via **Let's Encrypt**, provided your domain resolves to the WAF ingress IP (see [Step 4](#step-4-review-the-general-information-and-wire-up-dns)).
- **No TLS configuration is required on your side.** Certificate provisioning, renewal, and TLS termination are handled entirely by OVHcloud.
:::info
The real client IP is preserved and forwarded to the WAF engine via the `X-Real-IP`
and `X-Forwarded-For`
headers. IP-based rules on the `Advanced
` tab, which match the client `REMOTE_ADDR`
, work correctly without any additional configuration.
:::
## Reviewing the rule set
The `Rules
` tab lets you browse the OWASP Core Rule Set and any managed rules shipped with your configuration, and enable or disable individual rules.
A note at the top of the tab states the current enforcement mode and its effect: in **Blocking** mode matched rules are enforced with the action shown; in **Detection** mode they are logged only; in **Disabled** mode nothing runs.
### Summary cards
Three cards summarise the rule set:
- **Total rules** — the total number of rules, with the number of **active** rules beneath.
- **Built-in** — rules explicitly flagged as built-in.
- **Custom** — the remaining rules, including the managed Core Rule Set entries.
### Rules table
Each rule is displayed as a row with the following columns:
| Column | Description |
| :----------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Rule** | Rule name and ID (for example, "LFI Attack Detected #930100"), tagged built-in or custom. |
| **Category** | Attack type, for example `Path traversal / LFI`, `SQL injection`, `Cross-site scripting (XSS)`, `Remote code execution`, or `Scanner detection`. |
| **Severity** | Risk level: `Critical`, `High`, `Medium`, or `Notice`. |
| **PL** | The Paranoia Level at which the rule activates (1 to 4). |
| **Action** | The effective action, folded through the current mode: `Block`, `Log`, `Allow`, `Detect` (in Detection mode), or `Off` (when the rule or the WAF is disabled). |
| **Enabled** | A toggle to enable or disable the rule. |
### Rule actions
The **Action** column shows what the WAF does when a rule matches, once the current enforcement mode is taken into account:
| Action | Meaning |
| :--------- | :------------------------------------------------------------------------------------------------------- |
| **Block** | The request contributes to the anomaly score and is rejected with a `403` once the threshold is crossed. |
| **Log** | The match is recorded, but the request is allowed through. |
| **Allow** | The request is explicitly let through. |
| **Detect** | Shown while the WAF is in Detection mode: the rule is evaluated and logged, but never blocks. |
| **Off** | Shown when the rule is disabled, or when the WAF mode is Disabled. |
During the alpha, a rule's action is fixed by the managed rule set and cannot be changed from the console; you can only enable or disable each rule (see below). The overall enforcement behaviour (Detection, Blocking, or Disabled) is set globally on the `Protection
` tab.
### Searching and filtering rules
Use the filters above the table to narrow the list:
- The category dropdown restricts the view to a single attack type.
- The type dropdown filters by `All`, `Built-in`, or `Custom`.
- The **search box** filters by rule name, ID, or category.
The table is paginated (25 rules per page); use the `Prev
` and `Next
` buttons to move between pages.
### Enabling and disabling a rule
1. Locate the rule in the table, using the filters or search if needed.
2. Click the Enabled toggle on the rule's row to disable it, or click it again to re-enable it.
The change takes effect immediately. Disabling a rule silences it without affecting the rest of the rule set.
:::info
Custom-rule authoring is not available in the WAF Console during the alpha. You can enable or disable any rule in the managed set, and manage client IP lists from the `Advanced
` tab (see below).
:::
## Managing IP allow and block lists
The `Advanced
` tab lets you allow or block clients by IP. These lists are enforced as custom rules on the WAF instance (matching the client IP), evaluated **before**
the managed rule set.
The **IP whitelist**
card shows the current number of allowlisted and blocklisted entries, with a `Configure
` button.
### Edit the allow and block lists
1. On the Advanced tab, click Configure. A panel opens on the right side of the screen.
2. In the **Allowlist** field, enter one IPv4/IPv6 address or CIDR range per line. Allowlisted addresses are let through.
3. In the **Blocklist** field, enter one IPv4/IPv6 address or CIDR range per line. Blocklisted addresses are blocked.
4. Click Save to apply, or Cancel to discard.
The lists are saved as two dedicated custom rules on the configuration and take effect immediately. Emptying a list disables its rule.
:::info
Additional protection modules — **Bot management**
, **Rate limiting**
, **Threat intelligence**
, **Fraud prevention**
, **API security**
, and **Event forwarding (SIEM)**
— are listed on the `Advanced
` tab as upcoming features. They are not yet available during the alpha.
:::
## Investigating security events
The `Logs
` tab provides a searchable, time-ranged stream of the requests the WAF has blocked or detected, so you can investigate attacks and understand why each request was actioned.
- Use the time-range pills — Yesterday, Today, Past 3 days, Past 7 days, Past 30 days — to scope the stream. The default is Today.
- The list refreshes automatically every few seconds; a live indicator and the event count are shown above the table.
- Use the Verdict dropdown (`All`, `Blocked`, `Detected`) and the **Search path, IP, rule, reason…** box to narrow the results.
Each event is a row with the following columns:
| Column | Description |
| :----------- | :--------------------------------------------------- |
| **Time** | When the request was actioned. |
| **Verdict** | `Blocked` or `Detected`. |
| **Rule** | The ID of the rule that matched. |
| **Category** | The attack category, when known. |
| **Reason** | A short description of why the request was actioned. |
| **Score** | The anomaly score assigned to the request. |
| **Client** | The client IP address. |
| **Request** | The HTTP method and path. |
Click a row to open the **Security event** panel, which shows the full request details, including the matching rule and reason, plus the raw log line.
## Monitoring traffic and attacks
The `Metrics
` tab is a real-time dashboard of traffic volume, blocking, and where attacks come from.
Use the same time-range pills as the `Logs
` tab to scope the dashboard. It refreshes automatically.
- **KPI cards** — **Total requests**, **Blocked**, **Block rate**, **P99 latency** (last 5 minutes), and **Active connections** (now), each captioned with the selected range.
- **Traffic** — an area chart plotting requests per second and blocked per second over the range, with peak labels.
- **Blocked — by category** — a donut chart summing blocked requests by attack category (for example, `Lfi`, `Rce`, `ScannerDetection`, `DataLeakage`), with the total in the centre.
- **Top attacker IPs** and **Top attacked URLs** — bar lists derived from the security events in range.
:::info
Some metrics rely on a backend service that is not always available during the alpha; when it is unavailable, the affected values are shown as `—`.
:::
## Best practices
The recipes below cover the most common operational tasks during the alpha. Each builds on the steps in the **Instructions** section above.
### Onboard a new website safely
To start protecting a new website without risking downtime:
1. On the General Information tab, confirm the **Origin URL** points to your backend and that DNS resolves to the ingress IP (see [Step 4](#step-4-review-the-general-information-and-wire-up-dns)).
2. On the Protection tab, set the enforcement mode to Detection and apply.
3. Send representative traffic through the WAF for a few hours (manual traffic or shadow traffic from a load balancer).
4. Open the Logs and Metrics tabs and review the blocked categories and rule matches.
5. Tune any noisy rules on the Rules tab (disable them or rely on the anomaly threshold).
6. When the false-positive rate is acceptable, switch the enforcement mode to Blocking on the Protection tab and apply.
### Reduce false positives
1. On the Metrics and Logs tabs, identify which categories or rules are actioning legitimate traffic.
2. Choose one of the following remediations:
- **Disable** the offending rule on the Rules tab if it is not relevant to your application.
- **Lower the Paranoia Level** on the Protection tab to deactivate stricter rules.
- **Increase the Anomaly threshold** on the Protection tab to require more rule matches before blocking.
### Test changes without impacting users
1. On the Protection tab, switch the enforcement mode to Detection and apply.
2. Apply the rule or threshold change you want to evaluate.
3. Monitor the Logs and Metrics tabs to review what would have been blocked.
4. When the change is validated, switch back to Blocking.
### Restrict access by IP
Use the `Advanced
` tab to allow only trusted client IPs, or to block known malicious ranges. Because these lists are evaluated before the managed rule set, they are an effective first line of defence for restricting access to sensitive applications.
## Troubleshooting
If you encounter issues with the OWAF, work through the checks below.
| Symptom | Possible cause | Resolution |
| :------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Sign-in fails with the supplied token | The account access token is malformed or has been revoked. | Paste the token again exactly as received (a leading `Bearer` prefix is stripped automatically). If the issue persists, contact your OVHcloud contact for a new token. |
| Legitimate requests are blocked | A managed rule is firing on benign input,
or the Paranoia Level is too high. | Identify the rule on the Logs and Metrics tabs, then disable it on the Rules tab, lower the Paranoia Level, or raise the anomaly threshold on the Protection tab. See the [Reduce false positives](#reduce-false-positives) recipe. |
| The WAF is not forwarding traffic to the backend | The **Origin URL** is incorrect, the backend is unreachable,
or the WAF egress IPs are not allowed on your origin. | On the General Information tab, confirm the Origin URL and allow the listed **Egress IP** addresses on your origin's firewall. |
| Your WAF configuration shows `Degraded` or `Unreachable` | The WAF instance is unhealthy or could not be loaded. | Reload the page. If the status persists, report it to your OVHcloud contact. |
If the steps above do not resolve the issue, gather:
- The exact request that fails (method, path, headers, body sample).
- The matching rule ID and category from the Logs tab, if known.
- A screenshot of the Metrics tab when the issue occurs.
Then report the issue to your OVHcloud contact.
## Glossary
| Term | Definition |
| :---------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Anomaly Score** | Cumulative score assigned to a request. Each matching rule adds its score (5 by default). When the total reaches the threshold, the request is blocked. |
| **Anomaly Threshold** | The score value at which a request is blocked. Lower = stricter. |
| **Blocking Mode** | The WAF actively blocks requests that exceed the anomaly threshold. Recommended for production. |
| **Configuration** | A single WAF instance you manage in the console, identified by its name and slug. |
| **CRS** | OWASP Core Rule Set — the industry-standard open-source WAF rule set that the OWAF is based on. |
| **Detection Mode** | The WAF evaluates all rules and logs events, but allows all requests through. Used for testing. |
| **Egress IP** | The IP addresses the WAF connects to your origin from. Allow these on your origin's firewall. |
| **Ingress IP** | The public IP address clients reach the WAF on. Point your domain here. |
| **LFI** | Local File Inclusion — an attack that attempts to read files from the server. |
| **Origin** | The backend server that the WAF forwards legitimate traffic to. |
| **Paranoia Level (PL)** | A setting (1 to 4) that controls how many rules are active.
Higher levels activate more rules, increasing detection coverage and false positives. |
| **RCE** | Remote Code Execution — an attack that attempts to run commands on the server. |
| **SQLi** | SQL Injection — an attack that injects malicious SQL queries. |
| **SSTI** | Server-Side Template Injection — an attack targeting template engines. |
| **WAF** | Web Application Firewall — a security layer that inspects and filters HTTP traffic. |
| **XSS** | Cross-Site Scripting — an attack that injects malicious scripts into web pages. |
## Go further
Join our [community of users](https://community.ovhcloud.com/).