您仍然可以通过编程方式获取访问权限。他们已经删除了window.localStorage。这是一自有财产窗口实例，但它不是一个数据属性，它是一个accessor。访问者的get函数将返回localStorage与任何适当的接收器相关的值（thisarg)*。删除localStorage访问器对对象本身是否存在没有影响，因此再次访问它所需要做的就是找到另一个get localStorage()功能。幸运的是，您可以通过多种方式获得 - 每个 Window 对象都是用一种方式创建的。
// If we create an <iframe> and connect it to our document, its
// contentWindow property will return a new Window object with
// a freshly created `localStorage` property. Once we obtain the
// property descriptor, we can disconnect the <iframe> and let it
// be collected — the getter function itself doesn’t depend on
// anything from its origin realm to work**.
function getLocalStoragePropertyDescriptor() {
const iframe = document.createElement('iframe');
document.head.append(iframe);
const pd = Object.getOwnPropertyDescriptor(iframe.contentWindow, 'localStorage');
iframe.remove();
return pd;
}
// We have several options for how to use the property descriptor
// once we have it. The simplest is to just redefine it:
Object.defineProperty(window, 'localStorage', getLocalStoragePropertyDescriptor());
window.localStorage.heeeeey; // yr old friend is bak
// You can also use any function application tool, like `bind` or `call`
// or `apply`. If you hold onto a reference to the object somehow, it
// won’t matter if the global property gets deleted again, either.
const localStorage = getLocalStoragePropertyDescriptor().get.call(window);
如果这是一场军备竞赛，那么对隐藏 localStorage 感兴趣的一方可以尝试修补整个 DOM 中的每个方法和访问器，这些方法和访问器可以返回对其 localStorage 属性尚未被删除的窗口对象的引用。这比看起来更难做到。即使他们成功了，最终的决定仍将保留在用户端：浏览器扩展的清单可以声明一个内容脚本，该脚本将在文档加载时在任何其他代码之前进行评估。即使 CSP 也无法阻止它。 （一方面，这很糟糕……另一方面，如果没有这种功能，广告拦截扩展就永远无法工作。）
存储 API，无论是 sessionStorage 还是 localStorage，都不适用于保存敏感数据。它根本不受保护。尝试隐藏它暗示它可能被滥用 - 如果其作者认为删除该属性可以提供某种安全性，那么在该网站上输入敏感数据时您可能需要小心。
* 这里合适的接收器是任何没有被用户禁用存储的窗口对象（例如 Safari incognito）并且具有“非不透明”来源（意味着例如它在浏览器的about:blank页，因为存储需要与正常来源关联）。
旁白：关于全球品牌属性的额外好奇心。
** 与本源境界无关通常情况下，反正。然而，当接收者为 null 或未定义时，从 [Global] 接口上的 Web IDL 属性创建的属性可以表现出独特的行为，此时原始领域可能变得很重要。如果我们打电话给get功能与no接收器，例如
const { get } = getLocalStoragePropertyDescriptor();
get(); // ... null?
...然后它不会像典型的那样抛出 TypeError，而是返回 null。事实上，所有平台属性，而不仅仅是[全局]接口上的属性，都有一个默认接收器。默认接收器是创建函数的领域的全局对象，如果给定接收器为 null 或未定义，则会启动。 [Global] 情况的不同之处在于，此默认值实际上可以并且通常是valid接收器——也就是说，它可以是一个真正实现了属性为该接口的对象（任何其他函数最终仍然会抛出相同的 TypeError，所以你永远不会知道这个默认接收器）。
在该示例中，它默认为原始 iframe 中的窗口对象。它试图抓住它的localStorage对象，但由于 iframe 早已消失，所以它返回 null。我实际上不确定最后一个行为是在哪里指定的。我猜是not实际上是指定的，因为它与属性的 IDL 定义相矛盾。但这是有道理的（它必须做点什么），而且这就是 Chrome 所做的。在 Firefox 中，尝试这样做会导致内部引擎错误，这表明这种边缘情况可能没有得到太多考虑。
