SelfSecSelfSec
SelfSec WAF · Technical capabilities

Inspect. Decide. Block before your origin.

Follow the complete enforcement path: managed rules, signed virtual patches, request and response inspection, bot mitigation that injects nothing into your pages, and live evidence naming the rule behind every decision.

Join the launch listSee pricing
  • Pre-release
  • Nothing to install
  • Runs in front of any stack
Product evidenceProduct overview →
12Attack categories inspected inline
0Third-party code in the detection engine
DetectionThe mode you start in
2 recordsProve the name, then point it
ProtectionInspectionBotsSetup & controlObservability
The enforcement path

Inspect, then enforce

Each stage produces evidence for the next, keeping the workflow understandable from first contact to final action.

01

Point

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.

02

Observe

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.

03

Enforce

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.

04

Tune

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.

Baseline

The firewall you cannot question

Metered per request, per rule and per add-on, so the bill grows exactly when you are under attack. A customer's checkout gets refused and the rule that did it stays inside a black box — along with someone else's JavaScript, now running on your pages.

SelfSec

SelfSec WAF — flat, readable, reversible

One flat price, however many sites you protect and however much traffic they take. Every block names the rule behind it, a wrong rule is a correction we make on your word rather than a ticket into a black box, and enforcement only starts when you decide it should. Nothing is injected into your HTML.

Protection

Block the attack before it reaches your app

SQL injectionXSSTraversal & inclusionCommand injection & RCESSRFXXENoSQLProtocol anomaliesSigned bundlesECDSA P-256 or RSAPinned public keyDisk rules win collisionsSliding windowPer-route budgetsAutomatic temporary bansCIDR allow / denyIPv4 + IPv6

Inspection

Inspect the request, and inspect the answer

Card numbersAWS access keysConnection-string passwordsPEM private keysStack tracesMulti-pass decodingPlus-to-spaceCase foldingEvasion regression suiteOpenAPI 3Unknown path or methodUndeclared parametersJWT HS256 / RS256 / ES256

Bots

Bot mitigation that puts nothing on your page

No injected JavaScriptNo CAPTCHA vendorNo external requestsSigned clearance cookieJA3JA4Client-hello inspectionUser-agent versus TLS mismatchHeader shape

Setup & control

Prove the name, point it, and we operate the rest

Verify, then pointNo server to provisionAny stackRules operated for youObserve before enforcingRuntime mode changeSurgical correctionsSelf-service tuning on the roadmapNo dropped connections

Observability

See what was blocked, and what was never recorded

Threat feedMatched rule identifiersSeverity filterPath filterJA3 / JA4 per eventAuthorizationCookieX-Api-Key[redacted] before storageRule identifiers only0 third-party dependencies525 automated tests100 ms per-rule ceilingNo regex can stall a request
ProtectionInspectionBotsSetup & controlObservability
Protection

Block the attack before it reaches your app

3 capabilities in this category

12 attack categories, inspected on the way in

A curated core rule set spans 12 categories across 11 sets we enable independently: SQL injection, cross-site scripting, path traversal, local and remote file inclusion, OS command injection, remote code execution, server-side request forgery, XML external entities, NoSQL injection, HTTP protocol anomalies and known scanner fingerprints. Rules read the path, every query name and value, every header, every cookie and the body — so a payload hidden in a cookie is not a payload that got through.

Representative output

SQL injectionXSSTraversal & inclusionCommand injection & RCESSRFXXENoSQLProtocol anomalies

path · query names and values · headers · cookies · body

Virtual patches you can verify came from us

A virtual patch shields a known-vulnerable route in front of your origin while the application fix is written, tested and shipped. The part that usually goes unexamined is how the patch arrives: here a rule bundle is signed, and the firewall verifies that signature against an operator-pinned ECDSA P-256 or RSA public key before a single rule from it is applied. The distribution host does not have to be trusted, and rules already on disk always win an identifier collision.

Representative output

Signed bundlesECDSA P-256 or RSAPinned public keyDisk rules win collisions

unsigned or mis-signed bundle → rejected, previous rules kept

Abusive traffic sheds before your origin pays for it

Sliding-window rate limiting runs per client address, with separate budgets for the routes that deserve them, so a login endpoint and a static asset prefix are not measured with the same ruler. Repeat offenders earn an automatic temporary ban rather than being throttled forever, and allow lists and deny lists take CIDR ranges in both IPv4 and IPv6. Allow-listing always wins, including over imported threat-intelligence ranges — the list kept for your site is the one that decides.

Representative output

Sliding windowPer-route budgetsAutomatic temporary bansCIDR allow / denyIPv4 + IPv6

the allow list for your site outranks every feed we import

Inspection

Inspect the request, and inspect the answer

3 capabilities in this category

Secrets that leak on the way out are caught on the way out

Almost every firewall stops at the request. Response-side data-loss prevention reads what your application is about to send: payment card numbers, national identity numbers, AWS access keys and passwords embedded in connection strings are masked before the response leaves, with the content length corrected so nothing downstream breaks. A response carrying a PEM private key is not masked — it is discarded and the client gets a refusal. Stack traces, database error codes and framework error pages are recorded so you find out that a route is leaking internals before someone else does.

Representative output

Card numbersAWS access keysConnection-string passwordsPEM private keysStack traces

card number masked · private key never leaves the building

Evasion is decoded before matching, not after

A rule that only matches clean input is a rule that catches nobody. Requests are normalized before inspection — URL decoding, plus-to-space handling for query and form data, case folding — so double-encoded, mixed-case and percent-obfuscated payloads meet the same rule as the plain ones. The evasion suite is a regression test, not a claim: shipped rules are held to a dedicated set of encoded and mutated payloads that must still match, and clean traffic that must still pass.

Representative output

Multi-pass decodingPlus-to-spaceCase foldingEvasion regression suite

double-encoded payload → decoded → same rule, same verdict

Positive security: reject what your contract never described

Signature matching asks whether a request looks malicious. Schema validation asks a better question: is this request one your API ever said it would accept? Give the firewall your OpenAPI 3 document and it compiles operation-level checks at startup — unknown paths, methods your specification does not declare, query parameters that are not in the contract, content types you never published. JSON Web Tokens are validated at the edge with HS256, RS256 and ES256, and because acceptance is decided by the key material you provide, the none algorithm is not a bypass that exists here.

Representative output

OpenAPI 3Unknown path or methodUndeclared parametersJWT HS256 / RS256 / ES256

the contract you published becomes the contract that is enforced

Bots

Bot mitigation that puts nothing on your page

2 capabilities in this category

No third-party script, no CAPTCHA vendor, no account with anyone else

Every mainstream bot product works by putting someone else's JavaScript on your pages, which means another origin your users connect to, another vendor in your privacy policy and another thing that can break your checkout. SelfSec does not rewrite your HTML. When a client scores high enough on bot heuristics and is asking for a page, it gets a self-contained proof-of-work interstitial served by the firewall itself — no external request, no CAPTCHA provider, no tracking. Passing it sets a signed clearance cookie bound to that client. Being honest about the limit: this filters clients that will not run JavaScript; a determined headless browser will pass it.

Representative output

No injected JavaScriptNo CAPTCHA vendorNo external requestsSigned clearance cookie

your HTML is forwarded untouched — the challenge is served instead of your page, never inside it

Fingerprints below the application layer

A well-built bot will send a perfect browser user-agent. What it finds much harder to fake is the shape of its TLS handshake. The firewall reads the real client hello at the connection layer and computes JA3 and JA4 fingerprints, which are attached to the request and recorded on every threat event — so a client claiming to be Chrome while negotiating TLS like a Go program is visible as exactly that. Header-shape heuristics cover the rest: missing accept headers, implausibly thin header sets, browser claims without the metadata a real browser sends.

Representative output

JA3JA4Client-hello inspectionUser-agent versus TLS mismatchHeader shape

the handshake is harder to fake than the user-agent string

Setup & control

Prove the name, point it, and we operate the rest

2 capabilities in this category

Nothing to install, nothing to maintain

You prove the hostname is yours — a TXT record we hand you, or a file we ask you to serve — and protection starts when the name resolves to SelfSec instead of your origin. There is no package to download, no server to provision and no agent inside your application. Because the firewall sits in front of your stack rather than inside it, it does not matter whether your site runs on Windows, Linux, a managed host or a platform you do not control. Rules, updates and tuning are operated by SelfSec, and the next site you protect is another verified name rather than an infrastructure project.

Representative output

Verify, then pointNo server to provisionAny stackRules operated for you

prove the name → point the record → protection is live

Detection first, blocking when you say so

The reason teams put off deploying a firewall is the fear that it refuses a real customer on day one. So it does not start enforcing. A protected site begins in detection mode: every decision the firewall would have made is recorded, nothing is refused, and you read the log for as long as you need. Moving to blocking is a runtime change in the engine rather than a redeploy, and it reverses the same way, without dropping a connection. Corrections are surgical rather than all-or-nothing too — one rule, one path, one parameter — but today they are ours to make on your word rather than switches in your console. Putting that surface in your hands is on the roadmap.

Representative output

Observe before enforcingRuntime mode changeSurgical correctionsSelf-service tuning on the roadmapNo dropped connections

wrong rule for your app → tell us, and the rest of the set keeps enforcing

Observability

See what was blocked, and what was never recorded

3 capabilities in this category

Every decision, with the rule behind it

The console lists your protected deployments with live counters and shows the threat feed behind each one: time, client address, method and path, the reason it was stopped, the severity, the rule identifiers that matched and the JA3 and JA4 fingerprints of the client — filterable by severity, by whether the request was actually blocked, and by path. Reporting is near-real-time in the honest sense: batched and measured in minutes, not a live socket.

Representative output

Threat feedMatched rule identifiersSeverity filterPath filterJA3 / JA4 per event

every block carries the rule that made it

Credentials are redacted before anything is written down

A firewall sees every authorization header, every session cookie and every API key your users send. The safest way to handle that evidence is to never keep it. When a rule matches inside a sensitive header or a cookie, what is recorded is the string [redacted] — in the event store, in exports, in the log stream and in outbound alerts alike. Everywhere else the matched fragment is kept — capped at 120 characters, because a decision you cannot see the evidence for is a decision you cannot appeal — so what reaches your console is enough to judge an event and never a credential.

Representative output

AuthorizationCookieX-Api-Key[redacted] before storageRule identifiers only

the evidence field for a sensitive header is the literal string [redacted]

An engine with nothing else in it

The component that reads your traffic has 0 third-party dependencies — it is the platform's own standard library and nothing else, held to 525 automated tests. That matters for two reasons. A supply-chain compromise needs a supply chain to compromise, and a rule that catastrophically backtracks cannot stall your traffic, because every rule runs under a 100 ms match ceiling and a rule that exceeds it is abandoned for that field rather than allowed to hold the request.

Representative output

0 third-party dependencies525 automated tests100 ms per-rule ceilingNo regex can stall a request

a rule that misbehaves is dropped for that field · 100 ms ceiling, always

Where SelfSec WAF sits

Putting a firewall in front of an application is a choice about who processes your traffic and who carries the operating work. SelfSec is on the managed side of that line, and the table says so. Every claim below links to the source it came from.

What a block tells you

SelfSec WAF
The rule identifiers that matched, the severity, the reason and the request, with sensitive headers recorded as redactedSource
Cloudflare WAF
Managed rules are configured by override; rule expressions are not documented as customer-visibleCloudflare managed rules (opens in a new tab)
OWASP CRS on Coraza
Rules are open source and readable in fullOWASP CRS (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.

Put SelfSec WAF in your security loop

Join the launch list for product availability and deployment guidance.

Join the launch listSee pricingCheck availability