The path of a request.
Between the internet and your application, Ardarik reads every request, checks it, decides, and writes down what it decided.
It reads a request the way your application does.
Most attacks that slip past a gateway do so because the gateway and the server behind it understood the same request differently. Ardarik reads every address the way different servers would, and every form, document and upload the way the applications behind it would. When two readings disagree, the request is refused.
Two checks. One of them is yours.
The first is the OWASP Core Rule Set, the open catalogue of known attacks, on an engine we wrote ourselves in Rust.
The second is a profile of your own application: its pages, its fields, what normally goes into them. Ardarik learns it on your hardware, from your own traffic. The profile is part of the Enterprise edition.
Detect first. Prevent when you are sure.
Every application starts in observing mode: Ardarik inspects each request, records what it would have blocked, and refuses nothing. You see what blocking would do before it does it. Then you switch, for a whole application or for a single path, and back whenever you want.
It tells you why. It keeps almost nothing.
Every block comes with its reason in a sentence: which check objected, and to which part of the request. The log keeps the decision and the path. It never writes the query string, the headers, the cookies or the body.
At most one in a thousand.
The profile is calibrated for each application: it may block at most about one in a thousand legitimate requests. Until it has seen enough traffic to keep that promise, it blocks nothing.
Today Ardarik inspects the requests that reach your web applications and APIs. Inspection of responses, and of the network below, is planned. Ardarik is in development; there is no supported release yet.