SelfSecManaged web application firewall protection. One plan, unlimited protected sites, every inspection feature on — the capacity behind that is ours to run.
Unlimited protected sites with managed rules, virtual patching, TLS fingerprinting and every inspection feature the engine ships.
SelfSec is pre-release: nothing is charged today and this is the launch price. Prices are in USD and billed monthly.
The real question with a firewall is not the monthly price — it is who processes your traffic and who carries the operating work. Here is where each model lands, with every claim linked to its source.
| Capability | SelfSec WAF | Cloudflare WAF | OWASP CRS on Coraza |
|---|---|---|---|
| Deployment model | Managed reverse proxy in front of your originSource | Managed service on the vendor's global networkCloudflare WAF page (opens in a new tab) | Open-source engine you deploy as proxy, sidecar or libraryCoraza project (opens in a new tab) |
| Where requests are inspected | On SelfSec infrastructure, before forwarding upstreamSource | At the vendor edge the traffic is routed throughCloudflare WAF page (opens in a new tab) | Wherever you run the engineCoraza project (opens in a new tab) |
| Who maintains the rules | SelfSec, applied across every protected siteSource | Vendor security team, deployed network-wideCloudflare WAF page (opens in a new tab) | OWASP community ruleset you tune and operateOWASP CRS (opens in a new tab) |
| Virtual patching | Managed patch shields a vulnerable route; bundles are signed and verified against a pinned key before they applySource | Published as a CVE-blocking use caseCloudflare WAF page (opens in a new tab) | You author and maintain the ruleOWASP CRS (opens in a new tab) |
| Where enforcement starts | Detection mode first; a site moves to blocking when you ask, as a runtime change rather than a redeploySource | Managed ruleset actions are changed through overridesCloudflare managed rules (opens in a new tab) | Detection-only or blocking, configured by youOWASP CRS (opens in a new tab) |
| What a block tells you | The rule identifiers that matched, the severity, the reason and the request, with sensitive headers recorded as redactedSource | Managed rules are configured by override; rule expressions are not documented as customer-visibleCloudflare managed rules (opens in a new tab) | Rules are open source and readable in fullOWASP CRS (opens in a new tab) |
| Bot mitigation on your pages | A self-contained challenge served instead of your page; nothing is added to your HTMLSource | Challenges work by evaluating client-side signals in the visitor's browserCloudflare challenges (opens in a new tab) | Outside the rule set's scopeOWASP CRS (opens in a new tab) |
| Response DLP and schema validation | Premium tiers mask leaked secrets on the way out and validate requests against your OpenAPI contractSource | Not covered on the WAF product pageCloudflare WAF page (opens in a new tab) | Outside the rule set's scopeOWASP CRS (opens in a new tab) |
| What you set up | Hostname verification, then point the name at us; nothing installedSource | Nameserver change; CNAME setup on Business and aboveCloudflare onboarding docs (opens in a new tab) | You deploy and operate the engine yourselfCoraza project (opens in a new tab) |
| Published buying basis | One flat monthly price, unlimited sitesSource | Free, $25/mo Pro, $250/mo Business, contract tierCloudflare plans (opens in a new tab) | Free and open sourceCoraza project (opens in a new tab) |
| What you take on | Your traffic passes through SelfSec infrastructureSource | Your traffic and TLS traverse the vendor networkCloudflare WAF page (opens in a new tab) | Engine, rules, tuning and observability are yoursCoraza project (opens in a new tab) |
This compares deployment and operating models from published product information. It is not a detection benchmark, and free software carries operating cost rather than no cost. Verified July 25, 2026.
In two steps, and the first one is proving the name is yours: you publish a TXT record we give you, or serve a file at a path we name, so nobody can point a hostname they do not own at our edge. Then you point the name itself at SelfSec, and requests arrive here, are inspected inline and are forwarded to your origin. There is no package to download, no server to provision and no code change in your application — protection is live as soon as the record resolves.
Yes — that is how a managed firewall works. Requests to a protected site reach SelfSec first, get inspected and are then forwarded to your origin. We would rather you choose that deliberately than discover it later, so we state it on the product page rather than in a footnote: requests and responses are inspected inline, the metadata behind each enforcement decision is recorded, and full request and response bodies are never stored. The DAST scanner is deliberately the opposite: it runs on a machine you own and its core scan processing and findings stay there.
As many as you point at us. There is one plan, it has no site count to choose, and no inspection feature is held back — managed rules, virtual patching, bot mitigation, Response DLP, OpenAPI validation, JWT validation, signed rule feeds and TLS fingerprinting are all on for every protected site. Capacity behind that is ours to run, not something you size or pay for separately.
No. The firewall sits in front of your application rather than inside it, so your language, framework, web server and operating system are irrelevant to it — Windows, Linux, a managed host or a platform you do not control all work the same way. The only requirement is that you can change the DNS records for the name you want protected.
A managed rule that shields a known-vulnerable route in front of your origin while you ship the real fix — protection applies immediately, with no application code changes. Rule bundles are signed and verified against a pinned public key before they are applied, so a patch that reaches your traffic is one we actually published.
Start in detection mode and it cannot. The firewall ships observing rather than enforcing: every decision it would have made is recorded, nothing is refused, and you can read the log for as long as you want before a protected site is moved to blocking. That move is a runtime change in the engine, not a redeploy, and it reverses the same way. Moving a verified site between detection and blocking is a control in your console. What you cannot do yet is the surgical part: switching off a single rule, or exempting one path or one parameter, are still things you ask us for. Handing that surface to you is on the roadmap, and this answer will change when it lands.
You can see which rules fired, and not yet the rule set behind them. Every event in your console carries the rule identifiers that matched, the severity, the reason and the request that triggered it, so a block is something you can read and explain to a customer rather than an opaque vendor decision. What is not built yet is the other half — browsing the set itself, each rule with its name, attack category, severity and the parts of the request it inspects, readable before it ever fires. The engine already records all of it; the console does not show it yet. It is on the roadmap and this answer will change when it lands. Pattern bodies will stay inside your account rather than on a public page, so the set keeps working against the people it is meant to stop.
Protection is tied to your account, not to a key you install somewhere — there is nothing running on your side to configure. Every site you add is covered by the same subscription with the same feature set, and the console shows which sites are protected.
Nothing is charged during pre-release. The prices listed are the launch prices, checkout runs against a simulated provider so the account and subscription flow can be exercised end to end, and a real payment provider slots in behind the same flow before public availability opens.