这取决于您可以接受哪些风险。对于某些运行具有单独配置文件的浏览器的人来说就足够了。有些人会在单独的 Docker 容器中运行它。其他人将在 VMware、Virtual Box 或 QEMU 等虚拟机中运行它。

假设浏览器不存在漏洞——这在某些方面是一个危险的假设，但在我们加载启用脚本的网页时也是一种默认假设——只需使用私有/隐身窗口和浏览器的开发工具没有兴趣来源的页面（[[about:blank]] 或类似的通常可以正常工作）。

这样，脚本就不能利用任何存储的令牌（cookie 等）来了解有关您的浏览的任何信息或攻击您使用 XSS 或 CSRF 或类似方式登录的任何站点。它已经无法读取来自其他站点的响应或页面内容；开发工具仍受同源策略的约束。它可以发送请求（可能会暴露您的 IP 地址、用户代理字符串等），但它们将是匿名的，并且无法访问响应。

Javascript 旨在允许本地执行非受控代码 (*)。换句话说，要么你相信你的浏览器不包含任何破坏（你很勇敢，因为我不会）或者你相信服务器只包含无害的代码。

在任何其他情况下，我的建议是使用专用虚拟机，在查看可能不安全的页面之前拍摄快照，然后恢复快照。除非您面临针对您的虚拟机引擎的攻击，否则任何由 javascript 引起的操作都应该通过恢复快照来回滚。

(*) 从严格的安全角度来看，这意味着在咨询非受控站点的页面时应禁用 javascript。不幸的是，很少有现代网站可以以这种方式进行咨询......

最简单和最干净的方法是对您的测试平台进行 Dockerize 化。使用必要的测试框架、库、实用程序和代码快速启动容器，然后以隔离方式攻击目标代码和应用程​​序的能力非常强大。这将使您的爆炸半径最小化到意想不到的后果，这在处理不安全/不受信任的代码时更为重要。

如果容器不能满足所有需求或您的需求，那么无论是在本地使用 VirtualBox 还是使用某个云提供商远程使用 VM 都是一种选择。带着 DevOps 的思维方式，我尝试用干净、可重复、安全、自动化的解决方案来思考这类问题。能够扔掉东西并根据需要轻松地重新创建和定制它们是一种努力的模式。