Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. Enabling this feature in any API is one of the ways to prevent this attack.

CSRF Protect the request from other networks when they are sending a modifiable request in your system such as POST, PUT, DELETE, etc.

How CSRF Works?

In normal terms for every request requester must obtain the token from the same service provider by calling the same endpoint that the requester will use to send the modifiable data. To obtain the token from the service requester need to send the same request with GET/OPTION by passing “X-CSRF-Token” as the header and the value as “Fetch”. As result, you will receive the token which further in the call needs to pass as a value for the header “X-CSRf-Token”.

Implementation & Working of CSRF in HTTPS adapter

I’m currently using the trial version of SAP Integration Suit for the demo.

Create a demo IFlow in your environment and use the HTTPS adapter at the Sender side to provide your endpoint and check the box “CSRF Protection” in the Connection tab.

Sender HTTPS Apadter configuration

Deploy the IFlow and get the endpoint from monitoring. In this Iflow, I have used a content modifier to receive the dummy response.

Postman Configuration:

Once you get the endpoint, Open your postman and create a new request with HEAD/OPTION operation and provide the credentials in basic authentication and use the same endpoint generated by IFlow to get the CSRF token.

Note: CSRF token is only valid for IFlow from which you have generated it, you cannot use a token generated from one IFlow in another IFlow.

 Once you send the request in the response check header section and with the header “X-CSRF-Token” you will get the token that further need to use in the POST/PUT/DELETE request.

Note: This request will not be visible in the Integration Suit monitoring.

Token Response

Copy the token in 2^nd request with the same header and you will get your desired result.

Original POST request with token

We will try the same 2^nd request without passing this header and resulting in a 403 forbidden error.

Original POST request without token

This is how you can use CSRF can be configured and used in real scenarios for better protection.

Summary

In this blog, we get to the additional protection by enabling CSRF in your IFlow. This can be done for OData Adapter as well. Postman we can use for the testing of the IFlow before giving the endpoint to 3rd party.

Thanks for reading this blog. It will be helpful if you will provide your feedback in the comment section and follow for more similar content related to Integration (SAP PI/PO/CPI/IRPA).

Follow the community as well for better reach on more topics.

Integration Topic Page here | Integration Blog here