前端开发注意事项-web前端开发 后端开发

Web 安全是一个经常被前端开发人员忽视的话题。 当我们评估一个网站的质量时，我们通常会看性能、SEO友好性和可访问性等指标，而网站抵御恶意攻击的能力往往被忽视。 尽管敏感的用户数据存储在服务器端，后端开发人员必须采取重要措施来保护服务器，但最终，保护数据的责任由后端和前端共同承担。 虽然敏感数据可能被安全地锁在后端仓库中，但前端掌握着前门的钥匙前端开发注意事项，窃取它们通常是获得访问权限的最简单方法。

保护用户数据的责任由后端和前端共同承担。

恶意用户可以利用多种攻击媒介来破坏我们的前端应用程序，但幸运的是，我们可以通过简单地使用一些正确配置的响应标头并遵循良好的开发实践风险来很大程度上减轻此类攻击。 在本文中，我将介绍 10 件简单的事情，您可以采取这些措施来改进对 Web 应用程序的保护。

测量结果

在我们开始提高站点安全性之前，请务必就我们所做更改的有效性提供反馈。 虽然量化什么是“良好的开发实践”可能很困难，但可以相当准确地衡量安全标头的强度。 就像我们使用 Lighthouse 来获取性能、SEO 和可访问性分数一样，我们可以使用 SecurityHeaders.com 来获取基于当前响应标头的安全分数。

SecurityHeaders 能给我们的最高分是“A+”，我们应该一直努力争取。

响应头的注意事项

处理响应标头曾经是后端任务前端开发注意事项，但现在我们经常将 Web 应用程序部署到 Zeit 或 Netlify 等“无服务器”云平台，并配置它们以返回正确的响应标头成为前端任务。 确保了解您的云托管提供商如何使用响应标头并进行相应配置。

让我们来看看具体的安全措施。

1.使用强大的内容安全策略

完善的内容安全策略（CSP）是前端应用安全的基石。 CSP 是浏览器中引入的一种标准，用于检测和缓解某些类型的代码注入攻击，包括跨站点脚本 (XSS) 和点击劫持。

强大的 CSP 可以禁用潜在有害的内联代码执行并限制域加载外部资源。 可以通过将 Content-Security-Policy 标头设置为以分号分隔的指令列表来启用 CSP。 如果您的站点不需要访问任何外部资源，则标头的良好起始值可能如下所示：

Content-Security-Policy: default-src 'none'; script-src 'self'; img-src 'self'; style-src 'self'; connect-src 'self';

在这里，我们将 script-src 、 img-src 、 style-src 和 connect-src 指令设置为 self 以指示所有脚本、图像、样式表和 fetch 调用都应限制为与提供 HTML 文档的来源相同. 任何其他未明确提及的 CSP 指令将回退到 default-src 指令指定的值。 我们将其设置为 none 以指示默认行为是拒绝任何 URL 的连接。

然而，如今几乎所有 Web 应用程序都不是独立的，因此您可能需要调整此标头，以便您可以使用其他受信任的域，例如域名 Google Fonts 或 AWS S3 存储桶，但最好从最严格的政策，如果需要，稍后会放松。

您可以在 MDN 站点上找到完整的 CSP 指令列表。

2.启用XSS保护模式

如果用户输入确实注入了恶意代码，我们可以通过提供“X-XSS-Protection”：“1; mode = block”标头指令来指示浏览器阻止响应。

虽然 XSS 保护模式在大多数现代浏览器中默认启用，我们也可以使用内容安全策略来禁用内联 JavaScript，但仍然建议包含 X-XSS-Protection 标头以确保不使用旧版本的内联 JavaScript浏览器具有更好的安全性。

3.禁用iframe嵌入以防止点击劫持攻击

点击劫持是一种攻击，网站 A 上的用户被诱骗在网站 B 上执行某些操作。为此，恶意用户将网站 B 嵌入到一个不可见的 iframe 中，然后将 iframe 置于网站 A 上毫无戒心的用户的光标下，因此，当用户点击，或者更确切地说，当他们点击网站 A 上的某个元素时，他们实际上点击了网站 B 上的某些内容。

我们可以通过提供 X-Frame-Options 响应标头来防止此类攻击，该标头不允许在框架中呈现站点：

"X-Frame-Options": "DENY"

或者，我们可以使用 frame-ancestors CSP 指令，它可以更好地控制父级可以或不能将页面嵌入 iframe 的程度。

4.限制对浏览器功能和API的访问

良好安全实践的一部分是限制对正确使用我们网站所不需要的任何内容的访问。 我们已经使用 CSP 应用此原则来限制网站可以连接的域数量，但它也可以应用于浏览器功能。

我们可以使用 Feature-Policy 标头来指示浏览器拒绝访问我们的应用程序不需要的某些功能和 API。

我们将 Feature-Policy 设置为以分号分隔的规则字符串，其中每个规则都是一个特征名称后跟其策略名称。

"Feature-Policy": "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none';"

Smashing Magazine 有一篇很棒的文章详细介绍了功能策略，但大多数时候您希望为所有不使用的功能设置无。

5. 不要透露推荐人的价值

当您单击链接从您的站点导航时，目标站点将在引荐标头中收到您站点上最后一个位置的 URL。 此 URL 可能包含不应公开的敏感和半敏感数据（例如会话令牌和用户 ID）。

为了防止 referrer 值泄漏，我们将 Referrer-Policy 标头设置为 no-referrer：

"Referrer-Policy": "no-referrer"

在大多数情况下，这个值应该没问题，但如果您的应用程序逻辑在某些情况下需要您保留 referrer，请查看 Scott Helme 的这篇文章，他在其中分解了所有可能的标头值以及何时应用它们。

6. 不要根据用户输入设置 innerHTML 值

跨站点脚本攻击可以通过许多不同的 DOM API 进行，将恶意代码注入网站，但最常用的是 innerHTML。

我们永远不应该根据未经过滤的用户输入来设置 innerHTML。 用户可以直接操作的任何值——输入字段中的文本、URL 中的参数或本地存储项——都应该首先进行转义和清理。 理想情况下，使用 textContent 而不是 innerHTML 将完全避免生成 HTML 输出。 如果确实需要为用户提供富文本编辑功能，请使用专业的第三方库。

不幸的是，innerHTML 并不是 DOM API 的唯一弱点，易受 XSS 注入攻击的代码仍然难以检测。 这就是为什么拥有一个不允许内联代码执行的严格内容安全策略很重要的原因。

7. 使用 UI 框架

React、Vue 和 Angular 等现代 UI 框架内置了良好的安全性，可以在很大程度上消除 XSS 攻击的风险。 它们自动对 HTML 输出进行编码，减少对 XSS 敏感的 DOM API 的使用，并为具有潜在危险的方法（例如 dangerouslySetInnerHTML）提供明确且谨慎的名称。

8. 保持你的依赖是最新的

快速浏览一下 node_modules 文件夹，可以确认我们的 Web 应用程序是由数百（如果不是数千）依赖项组成的乐高拼图。 确保这些依赖项不包含任何已知的安全漏洞对于网站的整体安全性非常重要。

确保依赖项保持安全和最新的最佳方法是将漏洞检查作为开发过程的一部分。 为此，您可以集成 Dependabot 和 Snyk 等工具，它们将为过时或可能存在漏洞的依赖项创建拉取请求，并帮助您更快地应用修复程序。

9. 添加第三方服务前三思

Google Analytics、Intercom、Mixpanel等第三方服务，可为您的业务需求提供“一行代码”解决方案。 同时，它们使您的网站更容易受到攻击，因为如果第三方服务受到损害，您的网站也会受到损害。

如果您决定集成第三方服务，请确保设置尽可能强大的 CSP 策略，该策略仍将允许该服务正常运行。 大多数流行的服务都记录了它们所需的 CSP 指令，因此请确保遵循它们的指南。

在使用 Google Tag Manager、Segment 或任何其他允许组织中的任何人集成更多第三方服务的工具时，应特别小心。 有权访问此工具的人必须了解连接到其他服务的安全隐患，最好与开发团队讨论这个问题。

10. 为第三方脚本使用子资源完整性

对于您使用的任何第三方脚本，请务必尽可能包含完整性属性。 浏览器具有子资源完整性功能，可验证您正在加载的脚本的加密哈希并确保它未被篡改。

您的脚本标签如下所示：

值得注意的是，这种技术对第三方库很有用，但对第三方服务就没那么有用了。 大多数时候，当您为第三方服务添加脚本时，该脚本仅用于加载另一个依赖脚本。 无法检查依赖脚本的完整性，因为它们可以随时修改，因此在这种情况下，我们必须依赖严格的内容安全策略。