Show TOC

Cross-Site Request Forgery ProtectionLocate this document in the navigation structure

Use

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.

    Note

    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.

Note

Applicable for modifying requests with HTTP: If the HTTP status code 403 (forbidden) is displayed together with the information that a valid CSRF token is required, check that the profile parameter login/ticket_only_by_https is set to 0 (false) and not 1 (true) in transaction Maintain Profile ParametersRZ11. By setting the value of this profile parameter to 0, you can enable the use of cookies for HTTP.

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.

Note

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:

  1. Go to transaction SICF.

  2. Navigate to the ICF node for your service.

  3. Double-click your service node.

  4. On Service Data choose GUI Configuration.

    Caution

    The value of GUI link must remain Not specified.

  5. 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.

  6. Choose Continue and save your settings.

More Information