Types of Handlers and Attribute Inheritance

Global handlers, handler templates, individual handlers

Handlers are the program routines of the decider. They check the requests against the rules stored in vWAF. There are three groups of handlers:

Global Handlers always apply to an entire application and to all paths defined for that application. You can not modify the attributes of a global handler for individual paths. If preconditions exist for a certain path, these preconditions do not affect global handlers.
Handler Templates are also defined on application level. Their attributes are inherited by all paths, but other than with global handlers you can overwrite the attributes individually for a specific path. Also, you can delete a handler that was inherited by a handler template for a specific path.
On path level, you can either modify the attributes of inherited handler templates, or you can add individual Handlers that apply to that path only and aren’t passed on any further.

The variety of handlers from which you can choose depends on whether you’re adding a global handler or a handler template or individual handler. Global handlers can’t be used as a handler template and vice versa.

Optimum configuration process

To benefit from the inheritance mechanism, you should always first carry out global security settings with global handlers and handler templates on the application level. After this, you can modify special features of handler templates for individual paths if necessary.

As a result of the inheritance mechanism, the maintenance process also remains efficient: If you want to change a setting later on, you can do this centrally on the application level. You don’t need to repeat it for each path. Changes to a handler template are inherited automatically by all paths, but not by any paths for which you’ve changed the setting individually. All individual changes for a path are therefore always kept.

How many attributes have been inherited?

You can see at a glance how many attributes have been inherited and how many attributes are overwritten individually (Inherited Attrs column).

Which attributes have been overwritten?

When configuring a handler, vWAF shows you for each individual attribute whether its value has been inherited or overwritten individually (Inheritance and Owner columns).

How handlers are executed

If you’re planning to configure individual handlers in detail, it’s important to understand how vWAF executes handlers:

When you add a new handler to your configuration, this handler is inserted into the list of active handlers. The order is preset and can’t be changed. At runtime, vWAF executes all active handlers one after the other, according to their order on the list.

Basically, each handler is an autonomous process:

If the handler doesn’t detect any potential attack, the process continues until all configured handlers have been executed. Finally, vWAF accepts the request and passes it on to your web application.
If the handler, however, detects a potential attack, vWAF denies the request immediately so that it doesn’t get through to your web application. The process stops instantly, which means that all handlers that are queued after the triggering handler are ignored for this request.

Usually, handlers are unaware of each other. In some combinations, however, some specific handlers can process input passed by handlers that have been run prior to them. For example, there’s one handler that allows you to define a whitelist for the arguments of input form fields. If some of the arguments of a request match this whitelist, subsequent handlers are able to ignore the whitelisted fields and can focus on the other ones. This boosts performance and prevents conflicts.

If any handler impacts the behavior of another handler, you find a relating note in the reference description of both handlers (see Handlers).