Bug 207545 – Blocking Access to LocalStorage and SessionStorage for specific web-sites or for all websites doesn't work 100% of the time

• Component: WebKit API
• Status: NEW

[Brandon]

In order to block LocalStorage access or SessionStorage, developers need to inject some Javascript like like:
```
var localStorage = Object.getOwnPropertyDescriptor(window, 'localStorage');
if (localStorage) {
    Object.defineProperty(window, 'localStorage', {
        get: function() {
            console.error("Local Storage Blocked")
            return null;
        },
    });
}

var sessionStorage = Object.getOwnPropertyDescriptor(window, 'sessionStorage');
if (sessionStorage) {
    Object.defineProperty(window, 'sessionStorage', {
        get: function() {
            console.error("Session Storage Blocked")
            return null;
        },
    });
}
```

There should be a simpler way to deny a website or anything access to the storage. Currently, there is none.

[Alexey Proskuryakov]

Thank you for the report!

The title says "... doesn't work 100% of the time", can you elaborate on that?

[Radar WebKit Bug Importer]

<rdar://problem/59350812>

[Maciej Stachowiak]

If you add the cited script as WKUserScript using a WKUserContentController, it should be guaranteed to run before the page does anything. Using `evaluateJavaScript:` and friends instead would race with page loading.

Is there any other way in which the JS solution is not adequate?

[Brandon]

The problem is the page can grab the `localStorage` variable from an iFrame.

Example, if you inject the above script into the MAIN frame, but not all frames, then the following is possible:


```
var localStorage = document.querySelector('iframe').contentWindow.localStorage;
// Use localStorage to set values
```

This bypass currently works even on iOS 17. So even though you've blocked local storage for the main-frame, the main-frame can still access local storage via a secondary frame.