This section provides information about the extended CSRF (Cross-Site Request Forgery) protection for the SAP Gateway infrastructure.
A CSRF token-based protection has been introduced for all modifying requests. This will work in the following way:
Retrieve a CSRF token with a non-modifying request
SAP Gateway generates a CSRF token and sends it back in the HTTP response header field X-CSRF-Token. This happens in a non-modifying request (such as GET) if the header field X-CSRF-Token with the value Fetch is sent along with the non-modifying request. The ICF runtime also sends this CSRF token to the client, in the form of an "anti-XSRF cookie". The cookie name is sap-XSRF_<SID>_<client>.
Modify the request without CSRF token
For all modifying requests the application must include this token in an HTTP request header field with the same name (X-CSRF-Token). The framework checks for all modifying requests the validity of the CSRF token in the request. The validation is done by the ICF runtime that checks against the token from the "anti-XSRF cookie". If the validation fails an HTTP status code 403 (Forbidden) is sent back.
A valid CSRF token is not included in the response of a failed request.
Modifying request with CSRF token
In case a valid CSRF token is sent along with a modifying request the validation succeeds and normal processing continues.
If any internal errors occur during CSRF token retrieval or validation an HTTP status code 500 (Internal server error) is sent back and a RABAX message is generated.
This extended CSRF protection has the following consequences for clients:
Because modifying operations need to be provided with the CSRF token, a non-modifying request (such as GET) must be sent beforehand to retrieve the token.
A CSRF token is only generated after authentication on the server. Therefore, modifying operations for public services that do not require authentication, are not supported by the CSRF token-based protection.
Cookies must be sent back to the server. HTTPS must be used if the server sends secure cookies.
SAP Gateway offers two CSRF protection mechanisms
CSRF token check
Set as the default CSRF protection mechanism based on the token exchange principle. This is the default for the OData Standard Mode. See also ICF Services.
CSRF header parameter check
Additional parameter in the HTTP header X-Requested-With=XMLHttpRequest for modifying operations as protection mechanism. This is the default for the Compatibility Mode for SP02.
The OData Standard Mode can also be configured to use the Compatibility Mode for SP02 protection mechanism. This is only recommended in case of compatibility issues with the outside consumption or if your client application relies on the old protection mechanism.
Compatibility Mode uses X-Requested-With=XMLHttpRequest for downward compatibility reasons. As soon as the client applications are adapted we strongly recommend switching to the CSRF token check approach.
Changing the Default CSRF Protection Mechanism
To change the default CSRF protection mechanism, proceed as follows:
Go to transaction SICF.
Navigate to the ICF node for your service.
Double-click your service node.
On Service Data choose GUI Configuration.
The value of GUI link must remain Not specified.
Enter the following values:
Parameter Name: ~CHECK_CSRF_TOKEN
Parameter Value: 0/1 (disable/enable)
Compatiblity Mode for SP02 – HTTP Handler in SICF (node sdata)
(Default : X-Requested-With, to enable XSRF check use, ~CHECK_CSRF_TOKEN=1)
The request handler is /IWFND/CL_SDATA_ODATA_APP.
Standard Mode – HTTP Handler in SICF (node odata)
(Default: XSRF check, to disable and switch to X-Requested-With, use ~CHECK_CSRF_TOKEN=0)
The request handler is /IWFND/CL_SODATA_HTTP_HANDLER.
Choose Continue and save your settings.