单页应用程序 (SPA) 作为数字数据交付和客户参与的易于开发的界面，正在迅速获得更强大的立足点。
单页应用程序（SPA）因其易于开发且能够提供引人入胜的用户体验而变得越来越受欢迎。然而，SPA 也面临着独特的安全挑战。在本文中，我们将探讨保护 SPA 安全的困难，并讨论一种有前途的解决方案，称为令牌处理程序模式。
传统网站有一个服务 HTML 和数据的后端。用户身份验证通常发生在受网络防火墙保护的后端服务器上。然而，SPA 通过 API 连接到多个微服务，从而创建了更加分散的架构。虽然这种设置为 SPA 提供了轻量级优势，但它也带来了重大的安全风险。
主要挑战之一是用户身份验证必须经常在浏览器中进行，而不是在网络防火墙后面的受保护服务器中进行。这使得 SPA 容易受到各种类型的网络攻击，例如跨站点脚本 (XSS) 凭证盗窃。在这种攻击方法中，恶意行为者可以将代码注入浏览器，从而窃取访问令牌和用户凭据，最终授予他们对有价值的数据和系统的未经授权的访问权限。
另一个挑战来自于对第三方数据的大量依赖，这些数据通常通过 API 连接到应用程序。大量第三方连接可能会造成双重问题。
首先，开发人员无法控制其他从业者和组织创建的 API 中内置的安全性。这可能会导致在开发人员不知情的情况下将漏洞引入应用程序。
其次，在这种复杂多样的环境中编程可能会很乏味，因为涉及大量详细的、定制的代码和输入设置。很容易错过重要的步骤并在不知不觉中造成安全漏洞。此外，随着环境的发展和适应不断变化的业务需求，可能会引入隐藏的安全风险。
为了进一步说明这些挑战，让我们比较一下保护网站和 SPA 的设置。
在保护网站安全时，开发人员能够使用基于 cookie 的会话来授予用户对 Web 应用程序的访问权限。前端网站客户端在浏览器上存储 cookie，这些 cookie 会随着每个用户访问请求发送到单个后端数据服务器。授权决策可以基于存储中保存的会话数据，以便用户访问在网络防火墙后面保持安全。
此设置对于 SPA 来说是不可能的，因为单页应用程序没有专用的后端。内容交付网络 (CDN) 通常通过静态文件向 SPA 提供代码。这些文件通过 API 调用返回到应用程序。在 SPA 配置中，用户的会话无法保存在 cookie 中，因为没有后端数据存储。相反，访问令牌可用于代表经过身份验证的用户调用 API。
SPA 安全漏洞
SPA 安全挑战取决于基于浏览器的身份验证容易受到各种网络攻击类型的影响。一种威胁类型是跨站点脚本 (XSS) 凭据盗窃。在这种攻击方法中，恶意行为者将能够窃取访问令牌和用户凭据的代码注入到浏览器中，以获得对有价值的数据和系统的未经授权的访问。
虽然 XSS 是一种常见漏洞，但它并不是开发人员必须防御的唯一漏洞。更困难的是，修复一个漏洞往往会带来新的漏洞，这使得保护 SPA 成为一场永无休止的目标不断变化的游戏。例如，使用 OAuth 流通过 OAuth 令牌而不是会话 cookie 来验证用户或 API 访问似乎是减轻 XSS 攻击的好方法。
但是，如果这些令牌存储在本地存储中，威胁行为者可以轻松访问本地和会话存储以窃取令牌。如果可以刷新令牌，问题就会加剧，因为即使在用户会话结束后，攻击者也可以获得访问权限。
安全修复可能带来的意外问题的另一个例子是在内容安全策略 (CSP) 标头中构建强大的安全策略。虽然这可以添加另一层安全控制，但某些来源可能能够打开内容安全策略并禁用它们。
最重要的是，在防御对数据和系统的未经授权和恶意访问方面，浏览器是一个充满敌意的环境。任何安全措施都需要仔细测试和持续警惕，以确保关闭一种攻击媒介不会为另一种攻击媒介开辟道路。
同时使用 Cookie 和令牌
最近开发的用于保护用户身份验证免受恶意行为者侵害的 SPA 的一种保护方法是令牌处理程序模式，该模式合并了网站 cookie 安全性和访问令牌。通过实施令牌处理程序架构，从浏览器中删除身份验证并利用同站点 cookie 和令牌的后端到前端 (BFF) 配置，组织能够从 SPA 的轻量级方面受益，而无需牺牲安全性。
在此设置中，作为后端组件托管的 OAuth 代理位于 SPA 和授权服务器之间。 OAuth 代理处理 SPA 的 OAuth 流，并且不是向 SPA 颁发令牌，而是颁发仅安全的 HTTP cookie，SPA 可使用该 cookie 来访问其后端 API 和微服务。
托管在高性能 API 网关中的 OAuth 代理
以上是单页应用程序 (SPA) 安全性与网站不同的详细内容。更多信息请关注PHP中文网其他相关文章！
