Yesterday I installed Windows 8 and am now trying to understand why I am getting an "Access Denied" message when accessing localstorage. The page is being served on the same PC with the browser (http://localhost). My feeling is that one of the security settings in IE 10 is wrong, but I haven't figured out which one.

The line of JavaScript code triggering the error is:

if(window.localStorage.getItem('phone') == null)

The code works fine in the latest version of Chrome.


Our users were having issues with web sites using the LocalStorage feature (including Twitter) on Windows 8 with IE 10. When accessing one of these sites with the F12 Developer Tools open, a SCRIPT5: Access is denied message appeared on the console.

After working with Microsoft support, we identified the cause. It turned out to be a problem with the settings on the C:\Users\username\Appdata\LocalLow folder in their user profile.

Each folder on your computer has an integrity setting. More information about the purpose of this setting is here: http://msdn.microsoft.com/en-us/library/bb625964.aspx

The integrity setting on the AppData\LocalLow folder (and its subfolders) in each user's profile is supposed to be set to "Low" (hence the name). In our case, the integrity level was not set correctly on this folder. To rectify the problem, run the following command in a command prompt window:

icacls %userprofile%\Appdata\LocalLow /t /setintegritylevel (OI)(CI)L

(If there is more than one user account on the computer and the other users are having the same issue, the command needs to be run under each affected user's account.)

As for how this setting got changed in the first place? In our case, it was caused by a problem in the customized Windows 8 image we deployed to our workstations. For others that are having the issue, my research has revealed that the use of a "system cleaner" utility may be to blame.


Doubtless there might be many causes of the same symptoms, but here is what fixed this issue for me.

I had just one of many Windows 7 PCs with IE11 exhibiting the symptom of "Access Denied" on attempting any JavaScript involving window.localStorage from otherwise reputable and well-behaved web sites. Use of Process Explorer revealed that the proximal cause was an ACCESS DENIED when taskhost.exe (acting on behalf of Internet Explorer) tried to open DOMStore\container.dat for Generic Read-Write. In fact, it was worse than that: if I deleted container.dat, the same ACCESS DENIED occurred, even through the file did not exist any more. And, if I deleted the (hidden) DOMStore folder, when taskhost.exe attempted to recreate it, that received ACCESS DENIED as well.

After two days of chasing false leads, the final solution was this:

The registry entry:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore\CachePath

(do note the LowCache in that string) was incorrectly set to:

%USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore

when it should be:

%USERPROFILE%\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore

with the consequence that low-integrity localStorage requests were being directed to medium-integrity regions of AppData disk storage, thus generating ACCESS DENIED errors, and killing the use of JavaScript window.localStorage.

This registry entry must have been wrong for many years: perhaps a side-effect of enthusiastic take-up of buggy platform previews and so on. This error survived a total removal and re-installation of IE11.

There is a similar-looking registry entry for the medium-integrity cache:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache\DOMStore\CachePath

and that is correctly left as:

%USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore

and should not be changed.


Try enabling the Enhanced Protected Mode in the IE settings, under the Advanced tab, in the Security sub-list. This enables the Microsoft XSS filter. I had similar issues when logging into SE, and fetching google+ notifications, and my first workaround was starting IE with admin privileges. But I think the EP mode will do the trick in your case too.

Related links: Understanding Enhanced Protected Mode