Web application firewall (WAF): stop attacks without breaking your site
An injection slipped into a form, a flaw published in your CMS: one request is all it takes to reach your data. Klacos reads every request before it reaches your server and stops the ones probing for a weakness. It watches first, shows you what it would have blocked, and an exception takes one click, so your customers don’t pay for a rule that’s too strict.
Why so many sites leave their firewall off
Refusals that cost money
An order form rejected, an editor who can no longer save an article: all it takes is one field that looks like an attack. After an incident like that, the firewall often stays off.
Flaws patched too late
Between a flaw being announced in your CMS or a plugin and the update reaching your site, days go by. All that time, the flaw is public.
Requests judged one by one
Whoever is testing your forms for an injection isn’t an ordinary visitor on the rest of your site either. A firewall that judges each request in isolation can’t know that.
These attacks go after the application itself: its forms, its APIs, its plugins. They’re automated, and a published flaw gets tried in bulk by scripts well before most sites have installed the update.
What you should expect from a web application firewall: that it shows you what it would block before it blocks, that an exception doesn’t mean switching everything off, and that it knows who is sending the request.
Start by watching, block when you’re ready
Each site has a single setting: off, watching, then blocking at a sensitivity you pick. While it watches, nothing is refused. The console lists every match by rule, by path and by address, and flags the ones that look like false positives: you see what the firewall would have stopped on your own traffic, and who.
From any match, you create the exception that fits: this path, this parameter, this rule. The field in your article editor that holds HTML keeps its HTML, and the rest of the site stays protected. Once the list is clean, you switch to blocking, then raise the sensitivity if you want to.
A blocked request gets a page with its reference, or a structured response for an API. You find it in the console with the rule that stopped it, like every decision Klacos explains.
A firewall you tune, rather than one you put up with
Common attacks
Virtual patching
The whole request
Disguised attacks
Watch mode first
One setting
One-click exceptions
Tied to bot protection
Run it as a managed service in the European Union, or on your own servers, console included.
A published flaw, blocked before you update
When a flaw is announced in software you run, a virtual patch stops attempts to exploit it in front of your site as soon as it’s in place. You update at your own pace, without leaving the door open in the meantime.
We keep the rules up to date: there’s no list to download and no feed to subscribe to. A virtual patch buys you time; it doesn’t replace the update, which is the only way to close a flaw.
An attack says a lot about whoever sends it
The web application firewall and bot protection read the same visit. A rule that fires feeds into the view of that visitor: someone hunting for an injection in your forms gets a closer look across your whole site, even when their next requests seem harmless.
For a doubtful request, you can choose the invisible check rather than a block: a visitor’s browser passes it without showing anything, and an attack script has to get past it before going any further. Anyone firing attempt after attempt also runs into rate limiting, per address, per network and per route. The firewall is one part of your site’s protection as a whole: every capability in it shares the same read of each visit.
Questions about the web application firewall
Do I need to change my application?
No. The firewall is part of the service that sits in front of your site. Your code and your server stay as they are.
Does it replace updating my CMS?
No. It stops known attacks and gives you time to fix things, but a flaw stays open until the software is updated.
Are my APIs covered?
Yes. JSON and XML bodies are inspected like form data, and a blocked request gets a structured response with its reference, not an HTML page.
Does it protect against flooding attacks?
Request floods and connections that drag on are handled by rate limiting, per address, per network and per route. A volumetric attack that saturates the network link before it reaches a web service isn’t covered: that’s a job for your hosting provider.
Where is it run?
The managed service is run in the European Union. Klacos also installs on your own servers, as a Debian package or a Docker image, and the console can run there too.
See what the firewall would have stopped, before it blocks anything
Request early access: the firewall starts in observation, on your own traffic. Or talk to us about the forms and APIs you want to protect.