View source | Discuss this page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Add page
Show collection (0 pages)
Collections help


CSRF Protection


CSRF Attack.png

CSRF -or Cross-Site Request Forgery- is an attack where a malicious attacker makes a user’s browser to perform an unauthorized action on a trusted site for which the user is authenticated.

As the attacker has no way to receiver the command results, this attack is used to perform state-changing actions (i.e. changing a Product’s price) instead of simply fetching data. For a much more detailed discussion about this attack see CSRF Attack.

Starting from PR19Q1, both the Backoffice and the POS has protection against this type of attack. The approach followed in both cases consists of implementing the Synchronizer token pattern, which means that a random token is generated for each user session and this token should be sent along the state-modifying requests (POST, PUT and DELETE) to verify it comes from the user, which has access to this token.

Note that the generated CSRF token may change when there is a change in the User Session (i.e. when the user changes its role).

CSRF Protection in Backoffice

Standard Windows are protected against CSRF attacks out-of-the-box, both in grid and in form view.

The generated token is available in the client side in OB.User.csrfToken. This token is attached automatically to add/edit/remove operations and if not present, it will show a error message.

CSRF Protection in POS

POST requests sends automatically the User Session CSRF token as part of the request body. This token is also available in the client side in OB.MobileApp.model.get('csrfToken'). If the token verification fails, the server returns a 401 (Unauthorized) response.

There are 3 exceptions where it is not required to check the CSRF token although it is a POST request:

For the latter case, the AuthenticationManager abstract class implements the method markRequestAsSelfAuthenticated(HttpServletRequest request) to make the server bypass the CSRF token check for this particular request.

These scenarios had been taken into account in the DefaultAuthenticationManager and the MobileKeyAuthenticationManager, but this should be taken into account when implementing a custom AuthenticationManager to avoid receiving 401 responses for not sending the CSRF Token.

Retrieved from ""

This page has been accessed 195 times. This page was last modified on 19 October 2018, at 08:19. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.