为什么在单页应用程序中建议将API令牌存储在cookie中，当XSS取消CSRF时。
为什么在单页应用程序中建议将API令牌存储在cookie中，当XSS取消CSRF时。
很多关于在典型单页应用中安全存储令牌的方式的文章已经被写过了（使用cookies还是本地存储），并且使用cookies通常被认为是更好的选择。原因在于，在本地存储中存储会话数据容易受到XSS攻击的影响。虽然cookies有CSRF问题，但从文本中可以看出，实施CSRF防护不应该是一个问题。然而，我无法想象一个对XSS不容易受攻击的SPA的REST API如何实现CSRF防护（除非我们讨论重新认证和验证码）。甚至OWASP在CSRF预防备忘单中也提到：
“...任何跨站脚本漏洞都可以用来击败市面上所有的CSRF缓解技术（除了涉及用户交互的缓解技术...”
所以，如果cookies没有XSS问题但有CSRF问题，而如果存在XSS则CSRF是无用的，为什么它们被认为是更好的选择呢？如果这不是真的，有什么CSRF防护可以抵御XSS呢？
出现的原因是因为虽然将 API 令牌存储在 httpOnly cookie 中可以防止通过 XSS 访问令牌本身，但并不意味着应用程序不容易受到攻击。如果应用程序容易受到 XSS 攻击，那么在客户端上可以访问任何内容，包括 CSRF 令牌或在客户端上显示或处理的任何数据。只有 httpOnly cookie 中的登录/身份验证令牌是无法访问的，这意味着攻击者至少无法窃取会话。但这远远不足以保证免受 XSS 攻击的影响。
解决方法是采用以下方法来增强应用程序的安全性：
1. 使用 Content Security Policy (CSP)：通过 CSP，可以限制应用程序中可以执行的脚本和其他资源的来源。这可以减少 XSS 攻击的风险。例如，可以配置 CSP 以仅允许从特定域名加载脚本文件。
2. 对用户输入进行严格的验证和过滤：在将用户输入用于动态生成网页内容之前，必须对其进行适当的验证和过滤。这可以防止恶意脚本被插入到生成的网页中。
3. 使用安全的编码实践：确保应用程序在将用户输入输出到网页中时，使用安全的编码方式，例如将特殊字符进行转义，以防止 XSS 攻击。
4. 定期更新和升级应用程序的依赖库和框架：及时更新和升级应用程序使用的依赖库和框架，以修复已知的安全漏洞。
5. 进行安全审计和代码审查：定期进行安全审计和代码审查，以发现和修复潜在的安全问题。
通过采取这些措施，可以增强应用程序的安全性，减少 XSS 攻击的风险，即使在存储 API 令牌的 httpOnly cookie 中。