一周前，我在Atom论坛（下面的链接）上问了这个问题，但没有得到答复，因此我将其重新张贴在这里，希望有人能够对我的问题提供见解。
最近，我已经开始了一个使用Electron作为前端的开源项目。该项目有两个要求：它必须是跨平台的，并且必须具有嵌入式Web浏览器（该浏览器应该能够像典型的浏览器一样浏览Web并呈现内容）。考虑到Electron已经占用了我很大的空间，因此尝试在其旁边使用另一个嵌入式Web框架似乎是一个坏主意。因此，为了简化我的项目并保留构建在Electron之上的UI，我正在考虑使用Electron本身作为Web浏览器。这是我遇到的问题。
在Electron文档的安全性页面中，明确指出，
重要的是要了解……电子不是网络浏览器
此引用语的背景是，Electron或运行在其上面的代码具有与用户操作系统进行交互的独特功能，这与典型的Web应用程序不同。该页面继续说，
显示来自不受信任来源的任意内容会带来严重的安全风险，Electron不会处理此风险
此时，我很想放弃将Electron用作内置浏览器的想法，但在同一页面上，您仍然可以找到另一个非常有趣的花絮：
[要显示远程内容，请使用
<webview>标签或BrowserView，[并且]请确保禁用nodeIntegration并启用contextIsolation
链接：https://electronjs.org/docs/tutorial/security#isolation-for-untrusted-content
首先，关于使用Web视图，Electron自己的文档建议完全避免使用它们：
Electron的
webview标签是基于Chromium的webview，该标签正在发生重大的架构变化。这会影响webviews的稳定性，包括渲染，导航和事件路由。目前，我们建议不要使用webview标记，而应考虑使用其他选项，例如iframe，Electron的BrowserView或完全避免嵌入内容的体系结构。
链接：https://electronjs.org/docs/api/webview-tag
似乎无法避免嵌入内容，我选择使用BrowserView进行研究，但是我发现两者也不是很积极。就目前而言，建议是做两件事：
nodeIntegrationcontextIsolation查看完安全性和最佳实践页面后，我还将附加以下步骤：
webview元素并创建默认权限这是确保外部内容安全的大量步骤。更不用说，在最佳做法页面中还散布了一些其他警告，例如：
（关于在创建之前验证Webview选项的信息]
同样，此列表仅使风险最小化，它并未消除风险。如果您的目标是显示网站，则浏览器将是更安全的选择。
链接：https://electronjs.org/docs/tutorial/security#11-verify-webview-options-before-creation
（禁用remote模块时]
但是，如果您的应用程序可以运行不受信任的内容，并且即使您对渲染器进程进行相应的沙箱处理，则远程模块也可以使恶意代码更容易逃脱沙箱并通过主进程的更高特权来访问系统资源。 >
链接：https://electronjs.org/docs/tutorial/security#15-disable-the-remote-module
更不用说，导航到BrowserView页面后，整个课程都被列为实验课程。
[这甚至都没有提到由Electron创建的新增攻击面，例如去年webview组件中的漏洞：CVE-2018-1000136
现在，考虑到以上所有因素，许多开发人员仍然选择创建使用浏览器定期使用Electron消费外部和不受控制的内容的Web浏览器。
浏览器使用Electron（直接从Electron网站链接）：
对我来说，为了方便起见，将用户提交上述安全隐患似乎是不负责任的。
话虽如此，我的问题是：您能否安全地确保您的用户的完整性，使用Electron为不受控制的内容实现Web浏览功能？
谢谢您的时间。
链接到原始帖子：https://discuss.atom.io/t/security-implications-in-electron-as-a-web-browser/70653
一周前，我在Atom论坛（下面的链接）上问了这个问题，但没有得到答复，因此我将其重新张贴在这里，希望有人能够对我的观点提供见解。 。
一些不适合在注释框中输入的想法：