Skip to Content
Technical Articles

FAQ: SameSite Cookie and Direct Live Connections in SAP Analytics Cloud

*Update*: This FAQ was originally created to provide answers to frequently-asked questions about the SameSite cookie attribute and Direct live connections in SAP Analytics Cloud. Over the time, there have been questions beyond the scope of Direct live connections, so I will be appending some of those questions to the blog post.

Google Chrome will start to roll out a disruptive change related to Third-Party Cookie in the week of Feb 17, 2020, which will cause all Direct live connections in SAP Analytics Cloud to fail. I have written a blog post Direct Live Connections in SAP Analytics Cloud and SameSite Cookies to explain the problem and our solutions in detail, and I would like to take this opportunity to cover some of the most frequently asked questions.


Q1: What are the impacted scenarios?

A:All Direct live connections, including SAP HANA on-premises, HANA on SAP Cloud Platform (SAPCP) Cloud Foundry (CF), SAP Business Warehouse (BW), SAP S/4HANA, SAP Business Planning and Consolidation (BPC) and SAP BusinessObjects Business Intelligence Universe (BI Universe). Live connections to SCP Neo HANA and S/4HANA Cloud Edition are not impacted. The deprecated PATH-based live data connections are not impacted.


Q2: I have Google Chrome 80, but it seems that I am not impacted. Why?

A: Chrome 80 was released on Feb 4, 2020, without this disruptive behavior turned on. Google will start to roll out the new behavior to Chrome 80 in the week of Feb 17, 2020 in a phased approach, i.e. not all Chrome 80 users will get this disruptive “feature” turned on by default right away.


Q2: Does the solution require a system downtime?

A: Yes. The configuration changes on the systems require a system restart to take effect, so plan the system downtime accordingly. In case of SAP HANA, as the only component that needs restart is the built-in Web Dispatcher instead of the entire HANA system, usually it takes less than a couple of minutes to restart, which might make the downtime planning a little easier. Be careful with configuring the parameters when copy & pasting, which could sometimes add unwanted whitespaces, line breaks, etc, as wrong parameters could potentially cause startup failure of the backend systems.

If there is not enough time to plan the system downtime prior to Feb 17, 2020, you could temporarily turn off this new browser behavior. See the details in the Alternative Solution section in the blog post. Note that this setting can be turned off per site, so there shouldn’t be any security concern if it is turned off only for the SAP backend systems. See Q6 for more details.


Q4: What about other web browsers?

A: Microsoft Edge has a plan to adopt this cookie feature at a later time, but the exact date has not been published yet. The solution has already taken multiple browsers and their versions into consideration.


Q5: We have a Web Dispatcher in front of the backend systems for the Internet scenario / Load balancing scenario, and CORS was turned on in the Web Dispatcher instead of on the backend system. Should we follow the same steps?

A: We have always advised against enabling CORS on the Web Dispatcher, i.e. CORS should be turned on in the backend system directly according to our best practices. For this particular issue, the additional rewrite rules can be added either in the backend system or in the Web Dispatcher, but we do recommend putting the rewrite rules on the backend systems directly if possible.


Q6: With the solution, we are setting the SameSite cookie attribute to None. Does this reduce the level of security?

A: No. The SameSite=Lax default does not increase the security of SAP applications because they have already implemented protection against cross-site request forgery (CSRF) attacks. The only thing the rewrite rule does is to restore the previous default of SameSite=None. It does not cause any additional or new security risks. See more details in Note 2887651.


Q7: There are certain browser versions that are incompatible with the SameSite cookie attribute. Will the solution cause problems to those users?

A: The solution for SAP HANA on-premises and NetWeaver-based systems (BW, S4, BPC) has already taken browser compatibility into consideration, and will not issue the SameSite cookie attribute to incompatible browser versions.


Q8: Is it necessary for end users to clear browser cookies manually for the solution to take effect?

A: No. The cookies used in Direct live connections are session cookies instead of persistent cookies, so they are not stored to the end user’s disk. The solution is a 100% server-side solution.


Q9: Does the issue affect the SAML 2 Identity Providers used in initial SAC authentication and Single Sign-On in Direct live connections in any way?

A: No. In the context of 1) initial SAC user authentication and 2) SSO to Direct live connections, the SAML 2 Identity Provider is not considered a Third-Party site, therefore they are not impacted.


Q10: For direct live connections to HANA on-premise, BW, S4, BPC, we are adding a Secure attribute to all cookies as part of the solution to resolve this issue. Cookies with the Secure attribute will not be sent back to the issuing server. Would the solution impact other web applications on HANA and NetWeaver systems when accessed with plain HTTP instead of HTTPS? 

A: The ICM rewrite rule detects whether the web browser is accessing the service with HTTP. If that is the case, the Secure attribute will not be added to the cookies. This makes sure that the HTTP scenario is not impacted.


Q11: What is the impact to the SAC Mobile iOS app?

A: Going forward, the SAC Mobile iOS app will support iOS 13 and above only* (*subject to change in the future). In the embedding use case of SAC, SAC becomes the third-party cookie issuer, therefore SAC itself also needs to append the SameSite=None attribute to all its cookies. Due to an Apple iOS bug on iOS 12, all browsers on iOS 12, including embedded browsers, erroneously handle cookies with ‘SameSite=None’ as if they were marked with ‘SameSite=Strict’. This bug has been fixed in newer versions of iOS. More details can be found at SameSite=None: Known Incompatible Clients. As a result, now the SAC Mobile iOS app supports iOS 13 and above only*.


I hope the above FAQ has been helpful in clarifying any confusion with this critical issue.


Stay tuned.

You must be Logged on to comment or reply to a post.
  • Hello

    Just a question. If my SAC, IDP and also by live-connection are on HTTPS, does this rule still apply?


    Would it be possible to modify the CORS_rewrite script, so its only is effective on /bw/ina



  • Hello All,

    Quick question, does this issue also application if we are integrating SAC with BW/4HANA with CORS enabled by HTTP Whitelists and same solution is applicable as mentioned for BW system.




  • What would be code/rules for Apache server? We use that as a proxy instead of Web dispatcher for SAC Direct live connection to backend systems.

    • Please see Q5. We recommend putting the rewrite rules on the backend systems directly, instead of on the reverse proxy/load balancer.

      • The backend system is at a Netweaver version where CORS cannot be enabled directly. Hence it was activated on the load balancer/apache server. In this instance, I don’t see the samesite cookie rewrite rules working when activating in backend server. Looks like it needs to be activated on the apache server only. Since SAP admins are not well versed with Apache coding, will the rewrite rules also be provided for Apache web server?

        • Currently we don’t have a plan to release rewrite rules for Apache reverse proxy. What is your NetWeaver version, kernel version and kernel patch level, respectively?

          • Netweaver 750 SP5. Kernel 749 patch 500

            It would be valuable if SAP can also provide the rewrite rules for Apache server. This was built/used only for SAC purpose and us SAP Admins don’t have much coding information about the Apache rewrite rules.

          • You can apply the ICM rewrite rules in the blog post. Refer to Note 2887651, and you can see that your kernel version does support the required ICM rewrite rules.

            As a matter of fact, you don’t really need the Apache server to enable CORS in the first place. The entire ICM rewrite rules, including the section to enable CORS, and the section to add the SameSite attribute, can be implemented on the NetWeaver system directly.

  • Hi , We tried keeping code snippet in our Apache reverse proxy server, as mentioned in the note 2887651 (Also as per advise through SAP message).

    After that reverse proxy process started giving below error message. Any advise for the issue resolution?

    “Invalid command ‘SetHeader’, perhaps misspelled or defined by a module not included in the server configuration  ”

    AH00526: Syntax error on line 531 of D:/Apps/Apache24/conf/httpd.conf”



    • As mentioned in the FAQ and previous answers, it is recommended to implement the solution on the NetWeaver/HANA/BIP system directly, rather than on a reverse proxy.

  • hi Dong Pan

    Q1: What are the impacted scenarios?
    Live connections to SCP Neo HANA and S/4HANA Cloud Edition are not impacted.

    In our SAC connection scenario, we use Direct Live connections to SCP Neo HANA. However, during the past few weeks, some of our SAC users started to experience connection issue with Chrome, but not in other browsers.

    Apparently SAC Direct Live connections to SCP Neo HANA could also be impacted in this case. Do you have any suggestion or solution we can try? Thanks.


    • Hi Frank,

      If you are connecting to SCP Neo HANA system with a Direct live connection, you are not really treating it as an SCP Neo HANA system anymore. You are just taking it as a regular on-prem HANA system. Of course the problem would kick in in this scenario.

      Any reason why you are not using SAC’s built-in live connectivity to SCP Neo HANA?



  • Hi, what about Microsoft Edge with Chromium engine? It works for use with Google Chrome perfectly with samesite settings.. with Edge with Chromium engine it does not work…

    Are there some specific changes to be made by the usage of Microsoft Edge with Chromium engine

    • With the latest Edge (Chromium engine), I have not seen this issue in my tests, so the issue you are encountering could have been caused by something else. If the issue persists, I would encourage you to create a support incident to investigate further.