Feature Value
Type Protection
Risk Other
Covered by Agent/Library

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they are currently authenticated. CSRF attacks specifically target state-changing requests, not data, since the attacker has no way of seeing the response to the forged request. With a little help from social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests, such as transferring funds, changing their email address, and so on. If the victim is an administrative account, CSRF can compromise the entire web application.

More information

How to solve it

Hdiv adds an aleatory token to each link or form existing within the application, making it extremely difficult to implement a CSRF attack because the attacker does not know what the value is.

In order to offer the highest security level, Hdiv does not use an aleatory token per session but instead creates a new token for each requested page. Even the tokens used by links and forms within the same page are different, avoiding the reuse of link tokens to exploit a web form.

Agent Configuration

Hdiv agent supports different CSRF protection policies. In this section we will cover how they work and how they can be configured.

When will CSRF be validated?

Several configuration options can slightly modify this behavior but the following situations will be excluded from validation



The most simple approach is the token-based solution. In this case a random session token will be included in HTML forms and it will be required when they are submitted.

The following configuration options are supported


A token-based approach is the most widespread solution to contain CSRF attacks. However, not all scenarios can be solved with it. A token policy implies including a token inside a form. This may work in most cases but it will not be an option if for example a third party application (contained in a different domain) is targeting a POST url without requesting the form to the original domain. In that case the third party application will never send the token and therefore it will be blocked. A solution involving no code change, which is also transparent, is a domain whitelist approach.

By using this policy, Hdiv agent sends all the different domains that are targeting an application to Hdiv Console. All those domains are stored in the web console, making it really easy to create a whitelist of valid third party domains. Once it is created, Hdiv agent will only allow requests that need to be validated against CSRF (see the list above) when they come from whitelisted domains. Otherwise they are rejected.

The main features of this policy are, transparency (no additional information required), ease of update and being based on a whitelist.

The following configuration options are supported

NOTE: As it is transparent, its protection may not be detected by most scanners


The last option is a mixture of the previous ones. In this last option the token is included in the same way as in the first approach. When validation is needed, an attempt is first made to validate the token in the same ways as with the first policy. If the token is not valid, then the domain is validated using a domain whitelist as with the whitelist policy.