Enforce in front, not inside
Every request is evaluated against 12 attack categories before it is forwarded, stopping injection, protocol abuse, bots and abusive rates while they are still in front of your application.
Point your domain at SelfSec and every request is inspected inline before it reaches your origin — managed rules, signed virtual patches and bot mitigation, with every block naming the rule that made it, no software on your servers and no change to your application.
Synthetic live WAF preview showing requests inspected and blocked in front of an origin.
Start with the result your team needs, then inspect the technical depth behind it.
Every request is evaluated against 12 attack categories before it is forwarded, stopping injection, protocol abuse, bots and abusive rates while they are still in front of your application.
Shield a known-vulnerable route with a virtual patch while the application team ships the permanent fix. Rule bundles are signed and verified against a pinned key before they reach your traffic.
A block names the rule that made it and leaves an evidence trail you can inspect — not a vendor decision you have to defend to a customer without knowing what it was.
A clear path from first contact with the application to evidence your team can act on.
You prove the hostname is yours — a TXT record we give you, or a file we ask you to serve — and then point the name at SelfSec instead of your origin. Nothing is installed and your application code stays exactly as it is.
Protection starts in detection mode. Every decision the firewall would have made is recorded and nothing is refused, so you see what enforcement would do to real traffic before it does it.
When you say so, a site moves to blocking — a runtime change in the engine, not a redeploy. Clean traffic reaches your origin; blocked traffic gets an enforcement response with the matched rule recorded against it.
If a rule is wrong for your application, tell us and we correct it for you without giving up the rest of the set. Making that correction yourself is not in the console yet — it is on the roadmap.
Ask your current provider for the rule that blocked your customer's checkout. Here a rule is a record rather than a black box: what it is called, what it looks at and how serious it considers a match. Your console names the rules that fired on every event today; showing you the record behind them is on the roadmap.
Every event names the rule identifiers that matched. Reading the record behind them in your console is on the roadmap.
A correction is surgical rather than all-or-nothing — one rule, one path, one parameter. Today you ask us for it; the control is on the roadmap.
The same engine is one you could run yourself. Nothing about the rule set locks you to our hosting.
Pattern bodies will stay inside your account, not on a public page — the set has to keep working against the people it is for.
Scan the capability map here, then open the technical page for implementation detail and representative output.
Block the attack before it reaches your app
Explore categoryInspect the request, and inspect the answer
Explore categoryBot mitigation that puts nothing on your page
Explore categoryProve the name, point it, and we operate the rest
Explore categorySee what was blocked, and what was never recorded
Explore categoryRequests to a protected site are inspected on SelfSec infrastructure on the way to your origin. What is kept is the metadata behind each enforcement decision — full request and response bodies are never stored.
Read the Privacy PolicyDocumented flows
MANAGED EDGE · NAMED FIELDS
Requests are inspected on SelfSec infrastructure
Account activation is narrowly scoped
Optional telemetry stays off unless you turn it on
Join the launch list for availability, deployment guidance and the first production-ready release.