Skip to Content
Technical Articles

Best Practice for Using CSRF Protected Flag in CPI OData Adapter (Outbound)

Introduction

SAP Cloud Platform Integration has an OData receiver adapter (V2) that can be used to call OData services in the backend systems. It can be used both for reading (GET) and for changing (POST / PATCH / MERGE / DELETE) operations.

In the “Connection” properties of the OData adapter you will find the flag “CSRF Protected”. CSRF stands for Cross-site Request Forgery – a specific type of attack that exploits the trust that a site has in a user’s browser.

CSRF protection in the OData adapter works in a way, that technically two HTTP calls will be made to the OData endpoint. During the first call the OData adapter will only fetch the CSRF token and the second (real) HTTP call will be made with the token that was provided by the server in the previous response.

As technically two HTTP calls are made, the performance of the OData adapter call may suffer due to the overhead for the initial, technical HTTP call (including all network components that are typically taking part in the network communication).

Often switching CSRF protection off is also not an option, as many SAP OData services require CSRF protection for the normal functioning. If this option is disabled, the service returns HTTP error 403 – CSRF token validation failed.

Typical use case and procedure

In many customer scenarios integration flows are built in a way, that several OData calls are taking place. For example, first a call with GET operation checks an existence of an object in the backend system and depending on the result a subsequent POST or PATCH operation is called to perform a creation or change of the object.

In such kind of scenario you would like to minimize the number of technical HTTP calls that are made to the backend to achieve optimal performance. In order to eliminate unnecessary calls the following settings have to be enabled in your integration flow.

Step 1: Activate HTTP session reuse

OData adapter is capable of reusing CSRF token between the calls. E.g. that the token generated for the preceding GET call will be immediately reused for the subsequent POST call. In order for this functionality to work, the HTTP session reuse has to be activated. This setting is located in the Runtime options of the integration flow:

Set the value of this field to “On Exchange” to enable HTTP session reuse during processing of a single message.

Step 2: Disable “CSRF Protected” flag for the first OData call with GET operation

In the “Connection” properties of the adapter make sure that the flag is disabled.

Step 3: Enable”CSRF Protected” flag for the subsequent OData calls with changing operations

In the “Connection” properties of the adapter make sure that the flag is enabled.

With such kind of setup you should not have any additional HTTP calls to the backend while using the OData receiver adapter.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.