⚔️🔰JavaScript 安全🛡️⚔️

代码中的安全细节

当有人访问您的网站时，您的 JavaScript 代码会在他们的浏览器中运行，最终，他们有权读取您的 JavaScript 代码。因此，如果您有任何敏感数据，您的代码将会暴露这些数据，任何人都有可能看到。

例如：

切勿允许您的代码包含管理员密码...或 JS 代码中某处的任何密码。

如果有人想查看你的代码，只需打开浏览器的开发工具，点击“源码”，然后点击相应的 JS 文件即可。有时，如果他们使用 webpack 或类似的工具，webpack 生成的代码会显示在顶部，而人类可读的代码则会显示在底部。

在某些情况下，他们会看到一行代码，但为了让它更容易阅读，人们唯一要做的就是找到一个在线 JavaScript 格式化工具，然后粘贴它，然后轰！易于阅读！

另一方面，有些 API 可以帮助我们避免 API 密钥的泄露。其中一些 API 允许你根据 IP、域名等限制 API 密钥的使用。另一种避免共享安全凭证的方法是使用环境变量。如果出于某种原因，你需要在代码中保存一些敏感数据，我建议你将这些数据保存在服务器端代码中，比如 NodeJS。

😨 跨站脚本攻击，又称 XSS 😱

我不知道你们怎么想，但光是听到XSS攻击就让我毛骨悚然！

这种攻击只针对前端。我不是说后端一定不会存在漏洞，后端可能会存在漏洞，但不会受到 XSS 攻击。

这种攻击是指👹恶意 JavaScript 被注入并执行。

所以，它的工作原理基本上是，如果有人能够将一些代码注入你的应用程序，它就能做很多事情。想象一下，如果你访问谷歌或航空公司的页面，他们会通过访问本地存储等方式从 JavaScript 中收集大量信息。

感谢安全专家，较新的浏览器通过阻止标签在我们的 innerHTML 中执行。是的，你仍然可以注入，但它不会运行。

但是！总有一个但是。如果你通过 innerHTML 注入标签，你可以执行以下操作：

<img src="" onerror="alert('xss')/>

因此，当代码执行时，它会查找图像源。由于没有图像源，它会显示alert()。

您可以通过使用innerHTML来避免这种情况。您可以使用textContent。但有时您可能确实需要innerHTML。如果是这种情况，则需要在渲染代码之前对其进行清理。您可以使用一个名为sanitize-html的非常酷的 NPM 包来实现这一点。此包将“清理”您的文本并删除任何不需要的标签，以便不会执行任何恶意代码。您还应该在服务器端进行一些清理。我可以在表单中输入信息时盯着恶意代码，并且该代码将存储在数据库中。一旦渲染完成，它就可以执行。您应该在服务器到达数据库之前使用此 NPM 包。

第三方库

使用第三方库时，必须确保其安全性。有时，下载量或 GitHub 上的 Star 数量并不一定意味着这是一个安全的库。

查看这篇文章，了解一个关于某人如何使用 NPM 包窃取加密货币的非常有趣的故事。

NPM 会在安装包时运行漏洞扫描，从而提供一些帮助。注意：并非所有漏洞都有害！在慌乱之前，先做好调查。

跨站请求伪造（CSRF）

这种攻击是当有人诱骗您点击一个链接，该链接会引导您进入一个准备好的页面，他们会滥用您的本地 cookie，然后向您通常会访问的页面发送请求。

这更多的是一个服务端的问题，但值得一提。想象一下：

例如，你可能正在访问“x”网站，黑客会从你的本地存储中窃取你的部分信息。然后，他们会将你重定向到一个虚假网站，例如一个看起来像PayPal的网站。利用从你本地存储中获取的信息，他们可以操纵这些信息，将钱汇给你不想汇款的人。对于黑客来说，这可能是一个漫长的过程，但并非不可能。

这种攻击不仅适用于 NodeJS 或 JavaScript 技术，也适用于一般的 Web 开发。

CSRF 能被预防吗？是的。

有 3 种技术可以防止 CSRF 攻击。

1. 使用同站 Cookie 方法：这是一个新开发的属性，可以添加到您的 Cookie 中，以指示浏览器不允许第三方使用某些 Cookie。此属性由服务器设置，同时也会设置 Cookie 本身。

2. 质询响应：作为额外的保护措施，您可以要求用户在提交表单时进行质询响应。质询响应的一些示例包括：

-CAPTCHA 验证（非常流行）
-再次要求验证密码或一些个人信息
-发出一次性令牌

注意：对于需要高安全性的应用程序，应同时使用令牌和质询-响应来确保安全性。

3. 反 CSRF 令牌：当用户提交信息、与网站交互或执行任何其他生成 Cookie 的操作时，反 CSRF 令牌也应包含在 Cookie 请求中。之后，该请求将经过验证过程，在处理请求之前，会验证此令牌的真实性甚至是否存在。如果令牌缺失或不正确，则请求可能会被拒绝。

跨域资源共享，又称烦人的 CORS 😅

其概念是，来自浏览器端应用程序的请求只能发送到在同一服务器上运行的后端。

如果您出于任何原因将前端和后端托管在不同的服务器上，则可能会遇到此问题，但您可以通过在响应中指定标头来解决这个问题。默认情况下，浏览器不允许您与其他服务器“通信”，但使用正确的服务器端标头，您可以覆盖此设置。您可以使用 cors NPM 包或手动执行此操作，例如：

Node.JS 代码

app.use(function(req, res, next) {
  res.header("Access-Control-Allow-Origin", "*");
  res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
  res.json({data: [1,2,3,4]})
});

注意： CORS 概念适用于任何包含尝试与前端和后端交互的代码的 Web 应用程序。无论是 Node.js、PHP 还是其他任何语言。