SharePoint provider hosted add-ins stop working in Safari 13.1 browser

Published 06-25-2020 06:13 PM 6,398 Views

The Problem

When using the new Safari 13.1 browser with Intelligent Tracking Prevention (ITP), 3rd party cookies are not allowed by default to remove the ability for websites to track you using cookies.

When an iframe is hosted in a page, it's cookies, even if they are for the origin in the frame are considered 3rd party if it is hosted in a page that is a different origin. This causes the cookies set for the SharePoint add-in webpart model to not be sent on subsequent requests, including the authentication cookie (fedauth).


The Solution

There is a solution to this by adding some code to request access to these cookies via a storage access API that has been implemented in Safari, and Firefox, as well as browsers based on their respective projects (webkit and mozilla) and has experimental/future support in Chrome and Edge (chromium) as well.


This script code will allow you to request access to the 3rd party cookies-


//check if the function 'hasStorageAccess()' exists on the document object

//this lets you know that the storage access API is there

if(undefined !== document.hasStorageAccess){

    var promise = document.hasStorageAccess();


        function (hasAccess) {

            // Boolean hasAccess says whether the document has access or not.



        function (reason) {

            // Promise was rejected for some reason.

            Console.log("Storage request failed: " + reason);





If you have a SharePoint add-in that is running in an iframe in a SharePoint page, then you would add the above code to your provider hosted page.


If you run into problems with cookies, or authentication that only seem to affect the Safari browser, you can confirm that ITP is causing the issue by disabling the feature that is blocking third party cookies called Intelligent Tracking Protection (ITP).

To disable this setting, navigate to:

Preferences -> Privacy

Then uncheck the Prevent cross-site tracking option.

Disabling the feature for normal use is not recommended, as it is a security measure that is designed to block malicious scripts.


Future development testing

If you are developing a new SharePoint provider hosted add-in or an SPFx add-in that uses content in an iframe or calls to a 3rd party site (with another domain) then you can test the script above by turning on the Storage Access API feature in the experimental features.

In the MS Edge (chromium) browser use this URL-



In Chrome, use this URL-



Find and enable the 'Storage Access API' feature to enable the method used by the script.


There will likely be some updates here to clarify behavior.

1 Comment
Occasional Contributor

I hope this issue will have a proper way out.


Having third-party cookies disabled breaks all of my provider-hosted SharePoint apps, due to the fact that I'm performing client-side js calls using JSOM in them (which use SP.ProxyWebRequestExecutorFactory class to get past the cross-domain issue).


Recently lots of iOS users reported issues, due to the fact that third-party cookies have been disabled in their Safari browsers by default. It was not convenient for our users to have to manually update Safari's settings.


What is more, Google is planning to scrap third-party cookies in 2022. It basically means that all provider-hosted apps using JSOM will stop working in 2 years - this gives a very little time to react (when one has to deal with adjusting a number of applications). Frankly, I am pretty scared of where this is going.


Version history
Last update:
‎Aug 27 2020 03:39 PM
Updated by: