How OVHcloud WAF protects this origin

In the alpha, OWAF sits inline on the data path. DNS for your service points at the WAF ingress; only allowed traffic is proxied to the backend that serves this site.

Request lifecycle with OWAF

1. Client hits WAF ingress

Your domain (here, waf.success.ovh) resolves to the OVHcloud WAF ingress IP, not directly to this container.

2. TLS termination

In alpha, OVHcloud provides and manages the certificate. HTTPS is decrypted on the WAF so CRS can inspect the request.

3. OWASP CRS 4.x evaluation

Headers, body, URI, cookies, and query parameters are scored with anomaly-based rules across up to four paranoia levels.

4. Mode decides the outcome

Blocking rejects with 403 when the score threshold is met. Detection logs and still proxies. Disabled skips enforcement.

5. Proxy to origin

Allowed requests are forwarded over HTTP/HTTPS to your backend — in this lab, Traefik → nginx → /var/www/waf.

6. Operate in the console

Live stats (refresh ~15s), rule toggles, custom rules, and header policies are managed at labs.waf.ovh.net.

Path for this deployment

OWAF is the security control plane in front. Traefik and nginx remain the delivery path for content that OWAF has already allowed.

Browser
  → OVHcloud WAF (OWAF)  [CRS inspect · 403 or allow]
    → Traefik (Host waf.success.ovh)
      → nginx-waf container
        → /var/www/waf  (this website)

Protocols in alpha: HTTP/1.1 and HTTP/2. WebSocket is proxied but not deeply inspected yet.

Operator notes

Built-in rules

You cannot edit or delete CRS rules, but you can enable/disable them and override action or paranoia level.

Custom rules

Add targeted virtual patches (for example a Friday-evening CVE) without redeploying this static origin.

Roadmap

Public API, Terraform, customer certificates, and deeper Public Cloud integration come with beta/GA.