Under attack?

Docs — how the edge works

No fluff — just what you need to onboard a domain and understand what happens to a request once it reaches our edge.

Getting started

Onboarding is a DNS change, not a migration. Your origin server stays exactly where it is today.

  1. Add your domain in the portal.
  2. Point its DNS record (an A/AAAA record, or a CNAME) at the edge address the portal gives you.
  3. Once DNS propagates, live traffic flows DNS → edge (WAF) → your origin. We filter each request and forward the clean ones upstream.

We onboard early customers manually, so if anything about your setup is unusual, a human walks it through with you before you flip DNS.

What OWASP CRS 4.26 covers

The edge runs the OWASP Core Rule Set v4.26.0 on the Coraza engine. Two Coraza builds ship in one edge image — a proxy-wasm engine and a libcoraza FFI engine — and the engine is selected per route, so tuning one site never disturbs another.

CRS is an anomaly-scoring ruleset. Instead of a single rule deciding pass/block, it adds up signals across the request (suspicious paths, injection patterns, protocol anomalies) and acts on the total. That is what makes the common attack classes — SQL injection, cross-site scripting, path traversal, remote-file inclusion — catchable while keeping the false-positive threshold something you can tune rather than fight.

The challenge ladder

Not every suspicious request should be blocked outright, and not every visitor should see friction. When signals warrant it, the edge escalates through a ladder rather than jumping straight to a block:

  1. Proof-of-Work — a lightweight computational challenge, invisible to normal browsers, that costs automated clients real CPU.
  2. CAPTCHA — a pluggable interactive challenge (Turnstile or hCaptcha) for cases the proof-of-work rung does not settle.
  3. Web Bot Auth — cryptographic bot verification over RFC 9421 HTTP Message Signatures with Ed25519 keys, so a legitimate, declared bot can prove who it is instead of being challenged.

Each rung is opt-in and applies only where you enable it — the default path stays friction-free.

Certificates

TLS is handled for you. Each tenant is issued its own Let’s Encrypt certificate at the edge through the nginx-acme module, and renewal is automatic. You never upload a private key or run a certbot command — issuance and rotation live on the edge, which is also why LE private keys never leave it.

Docs FAQ

Do I have to move my hosting to use Smart WAF?

No. Your origin stays where it is. You only change DNS so traffic reaches our edge first; we filter it and forward the clean requests to your existing server.

Which WAF ruleset do you run?

OWASP Core Rule Set v4.26.0, executed on the Coraza engine. CRS is anomaly-scoring: it adds up signals across a request rather than matching a single rule, which keeps false positives tunable.

What latency does the WAF add?

We design to a ≤5 ms added-latency budget on normal traffic. That is a design target; production-hardware benchmarking is ongoing and any measured figure we publish is labelled with its environment.

Who manages the TLS certificate?

We do. Each tenant gets its own Let's Encrypt certificate, issued and renewed automatically at the edge — you do not upload or rotate keys yourself.