Google Identity Platform认证是否比传统HTTP-only Cookie更易受攻击？

问题背景 #

• 正在研究基于Firebase、Google Identity Platform（GIP）的无服务器Web应用认证架构
• 传统服务器架构中，使用HTTP-only Cookie存储认证信息，可防范XSS攻击或恶意Chrome扩展读取敏感凭证
• 测试GIP时发现，其SDK默认将认证响应（包括access token、refresh token及用户信息）存储在IndexedDB中，攻击者可通过注入的恶意脚本轻松提取这些信息，进而冒充用户
• 疑问：若存在代码注入攻击向量，这种存储方式是否比传统服务器架构的认证方案更脆弱？

补充说明 #

后续在官方文档中找到相关内容，其中探讨了HTTP-only会话Cookie相对ID Tokens的安全优势，并介绍了具体的创建方法。

解答 #

是的，在存在代码注入（如XSS）攻击的场景下，GIP SDK默认的IndexedDB令牌存储方式，确实比传统HTTP-only Cookie方案更脆弱。

核心差异在于：

• HTTP-only Cookie由浏览器HTTP协议层独立管理，前端JavaScript（包括注入的恶意脚本）无法读取或操作这类Cookie，从根源上阻断了XSS攻击对认证凭证的窃取路径。
• IndexedDB存储的令牌属于前端可访问的存储区域，一旦页面被植入恶意脚本，脚本可直接调用浏览器API读取其中的敏感令牌，随后就能以用户身份发起请求，完全实现身份冒充。

不过GIP也提供了兼顾安全与无服务器架构特性的解决方案：通过后端生成并下发HTTP-only会话Cookie，替代前端直接存储令牌的模式。这种方案既保留了无服务器架构的灵活性，又继承了HTTP-only Cookie的XSS防护能力。

内容的提问来源于stack exchange，提问作者AmitA