务必定期审查应用的安全性，因为任何疏忽都可能使您、您的团队、您的用户甚至服务器面临被严重利用的风险。不要因为觉得自己什么都知道就忽略这个页面。
我们为安全领域的新手收集了一些最佳实践，也为刚接触 Vue 生态的安全专业人员准备了一些见解。随着我们自身研究和出色的安全社区发布的成果，我们将持续修订和补充本文档。
Vue 安全风险
用户输入与 v-html 的危险性
v-html 指令是以编程方式渲染标记的好工具，但即使是 Vue 官方文档也附带了这个警告：
“在网站上动态渲染任意 HTML 非常危险，因为这很容易导致 XSS 漏洞。仅在受信任的内容上使用 HTML 插值，绝不要用在用户提供的内容上。”
如果您不理解这意味着什么，请快速了解一下 OWASP 关于 XSS（即跨站脚本攻击）的说明。
平心而论，这确实是好建议，但不要掉以轻心。务必像攻击者一样思考——他们会通过创新手段、社会工程学、欺骗、钓鱼和窃取等方式侵入您的系统。如果 webpack loader 出现漏洞并以恶意方式修改了您的页面怎么办？如果有人提交了一个用心不良的 PR 怎么办？如果突然间第三方 API 发生变化，开始发送相同结构但不同内容的数据怎么办？如果您以为安全的系统实际上已经被植入了后门怎么办？如果一个初级开发者不小心对代码做了根本性的破坏却没有得到妥善的代码审查怎么办？（是的，愚蠢有时候和恶意一样危险！）关键是，务必做好最坏的打算来应对意外情况，加固您所有的系统。
务必使用 v-pre 指令来额外增强安全性。
vue-i18n
Vue 的准官方国际化包允许您在键值中存储 HTML 并可能渲染它们。如果用户无法修改这些值，那应该没问题——但请确保您信任（即审查过）翻译人员！我们的建议是（虽然工作量更大且会减慢 HMR 速度）务必使用模板插值。
eval()
虽然您可能想使用 eval()，但即使您知道自己在做什么，也请不要使用。
Quasar 组件
一些 Quasar 组件和插件可以被配置为允许渲染"不安全内容"。这是一个选择性启用的功能，通过使用 *-html 类型的布尔属性来实现。下面将讨论这些组件。
QSelect
如果您没有自定义菜单相关的作用域插槽（即 option 作用域插槽），务必防止组件在标签和子标签中渲染 HTML（即不要通过组件属性启用它）。一般来说，这不是用户提供的数据。如果您自定义了这个插槽，那么清理（sanitize）工作就是您自己的责任了。
QChat & Emoji
QChatMessage 组件默认不会将内容显示为 HTML。但您可以通过 *-html 属性来启用它，在这种情况下您应该对内容进行清理。
TIP
近期出现了一些漏洞利用（特别针对旧版 Android 和 iOS 设备），某些 emoji 和非标准 UTF-8 字符实际上会触发移动设备重启和开机循环。务必考虑在纯文本类型的输入框中集成 markdown 解析，在服务端将其渲染为 HTML 后再传递给聊天接收者。
Loading
许多开发者要求 Loading 插件能够显示 HTML，因此这个功能默认已启用。但如果您担心安全问题，务必添加 sanitize: true，这样就消除了这个攻击向量。
Notify
使用 HTML 来美化 Notify 插件默认是未启用的，但如果您设置了布尔属性 html: true，那么清理工作就由您负责了。
Dialog
使用 HTML 来美化 Dialog 插件默认是未启用的，但如果您设置了布尔属性 html: true，那么标题和消息的清理工作就由您负责了。
QInput
任何允许用户输入按键、从剪贴板粘贴或拖放文件的输入框都是安全风险。我们不会深入探讨其中的细节，但请记住维护安全是您自己的责任。只有您才能防止安全事故的发生！
QEditor
这个组件允许用户实际创建 HTML（甚至粘贴 HTML）。如果您要保存它并展示给其他用户，服务端的验证是必不可少的。在这种情况下，务必过滤掉 <script></script> 和 <iframe></iframe>。您可以访问文档中的 v-html vs. double-moustache 示例来体验 QEditor 组件，查看两种渲染方式的效果。QEditor 没有 sanitize 标记。此外，如果您创建了自定义按钮，确保它们的安全也是您的责任。提醒在先。
处理文件
那么如何验证和清理文件呢？虽然这有点超出"前端框架"的范畴，但我们知道你们中的许多人也会在服务器上存储用户创建的文件。如果您只是存储它们（不做任何处理），务必通过检测魔数来验证文件是否为正确的类型。务必考虑使用 ClamAV 来检查文件是否包含已知的病毒特征。
图片
如果您允许用户上传图片到服务器，您应该知道许多常用模块仅仅检查文件后缀名。伪造一个表面上看起来像图片的文件非常容易。务必通过检查魔数来验证文件是否名副其实，为此可以考虑使用 is-image。虽然您可以使用这种方法在浏览器中检查魔数，另一种方法是让用户将图片加载到 canvas 中，然后直接从 canvas 上传。Vue-croppa 是一个很好的前端工具。
压缩文件
利用压缩文件解压进行目录遍历攻击是一个真实的安全问题，且在不解压文件的情况下几乎无法检测。如果您可以不接受这种类型的媒体文件，那就不要接受。否则，在 Linux 上务必使用 less / lesspipe 和 .lessfilter 来用自定义工作流预处理这些文件。
密码
不要以明文保存密码，事实上——不要保存密码本身。务必保存安全哈希值，并使用安全的盐和适当的算法在内存中计算它们。务必限制密码的长度（最小和最大字符数），但要确保上限足够高，使合法用户永远不会触及。务必考虑一个高度安全的密码重置流程，并允许用户根据自己的偏好来配置它。这个流程因项目而异，我们无法告诉您如何具体解决，但这里有一些好的参考链接：
密码学
- 不要创建自己的加密方案
- 不要以明文存储个人信息
- 不要创建自己的加密方案（故意重复强调）
- 不要忽略实现细节的任何方面
- 不要创建自己的加密方案（故意重复强调）
- 不要使用 MD5 或 SHA1
- 不要创建自己的加密方案
学习这个话题并选择工业级解决方案的好去处是 libsodium
发布
TIP
如果有人想要更改您的数据库中的内容或向服务器添加文件，而他们没有使用 SSH 密钥，务必对输入进行验证并且清理。
Web
- 不要使用 http
- 不要在 JWT 中存储敏感数据
- 务必使用 https / wss
- 务必手动审查您的证书
- 务必验证用户身份
- 务必记住 JWT 本身并不加密
- 务必使用 JWE 代替 JWT，并使用 AES256 CBC + HMAC SHA512
- 务必深入执行完整的 OWASP Web 审计
Cordova / Capacitor
- 不要使用 iframe
- 不要为 Android Gingerbread 打包
- 务必对所有构建进行签名
- 务必加密所有静态数据
Cordova 文档页面详细介绍了 Cordova 的安全防护，虽然看起来有些过时，但信息大体上仍然是有效的。
Electron
Electron 是一个非常特殊的情况，因为 XSS 和远程代码注入实际上可能导致终端用户（甚至开发者）设备的完全沦陷。
- 不要禁用
websecurity - 不要启用远程代码执行
- 务必阅读我们关于增强 Electron 安全的指南。
SSR
当您使用 SSR 模式生成项目时，会提供一个最小化的 Express 服务器。加固您的环境以保护服务器和用户是您的责任。为此，我们提供了一系列重要的 HEADERS 供您参考，您应该在项目进入生产阶段之前有选择地启用它们（见 src-ssr/index.js）。重要的是要记住，HEADERS 并非万能的，因为它们需要浏览器厂商来遵守——例如，如果您的 Content Security Policy 使用了 sandbox 值，Chrome 会导致 PDF 查看出问题。
- 不要忘记设置限制性的 headers
- 不要认为仅靠 headers 就能保护您免受所有攻击
- 务必了解 headers 相关知识
环境安全
更安全意味着需要考虑很多因素，您遵守的以下准则越多，攻击面就越小。
运维安全
审查您的开发系统如何运作：
- 不要保留不需要的软件
- 务必使用占用更小且启用了安全功能的操作系统和发行版（例如 SELinux）
- 务必确保您机器上的所有软件都是最新的（尤其是 NODE）
- 务必使用密码管理器
- 务必尽可能使用双因素认证（2FA）
审查您的生产环境如何运作：
- 不要以为隐蔽性安全（security through obscurity）在遭受攻击时能帮到您
- 不要保留不需要的开放端口
- 不要假装容器或虚拟机天生就能保护您
- 不要停止保持警惕
- 务必关闭服务器的密码和 root 访问
- 务必使用安全的传输协议（SSH、HTTPS、SFTP、WSS）
- 务必安装 fail2ban 和 rkhunter
- 务必定期分析日志
- 务必加密静态数据
- 务必使用高级媒体类型分析
- 务必使用 ClamAV 检测受感染的文件
- 务必定期进行系统维护
- 务必从允许/可用类型中移除旧的密码算法
- 务必使用 CSP headers 保护用户
组织与仓库安全
这是每个团队都应该关注并认真思考的问题。务必考虑谁有权访问您的仓库、提交如何被合并以及资产如何被发布。以下是一些值得记住的要点：
- 不要在源代码中放置敏感数据
- 不要忽视
yarn audit或npm audit的报告 - 不要盲目依赖第三方服务
- 务必在合并到 master 之前要求代码审查
- 务必要求审查者/代码提交者启用双因素认证
- 务必要求签名提交
- 务必认真对待 GitHub 安全警告
- 务必进行深入的代码审查
- 务必审查关键的第三方库，尤其是处理真实文件的库
- 务必锁定关键库的版本
- 务必提交 package lock 文件
- 务必将
.env文件添加到.gitignore
最后的话
安全不是安心，它是一种需要保持警惕和意识的知识实践。不要停止关注安全，不要认为自己做得已经够好了。总有更多可以做的事情，总有新的漏洞需要了解。但最大的安全威胁是懒惰，所以打起精神来，回到页面顶部，务必阅读关于 XSS 的 OWASP 链接。我们不会告诉任何人的。