Apollo 2.0中用apollo-link-state缓存isAuthenticated是否存在安全风险？

首先直接给结论：把isAuthenticated存在apollo-link-state的客户端缓存里确实存在安全风险——用户完全可以直接修改这个状态来绕过前端的访问限制。

为什么有风险？ #

Apollo Link State的缓存本质上还是存在浏览器端的内存或本地存储里（取决于你的配置），用户只需要打开浏览器开发者工具，找到Apollo的缓存存储，就能轻松把isAuthenticated的值改成true。这时候如果你的前端路由守卫或者UI逻辑完全依赖这个状态来控制访问，用户就能直接进入原本需要认证的页面。

而且不止Apollo缓存，任何前端状态存储方案（Redux、localStorage、sessionStorage）都存在这个问题——只要是客户端可控的状态，都不能作为权限控制的可靠依据。

更安全的处理方式 #

前端状态可以用来做UI展示和交互逻辑，但真正的权限控制必须交给后端，这里有几个关键要点：

• 后端接口强制验证：所有需要认证才能访问的接口，必须在后端校验用户的身份凭证（比如JWT令牌、sessionId）。就算用户篡改了前端的isAuthenticated，发起请求时后端发现凭证无效或无权限，依然会拒绝返回敏感数据，这样用户就算进了页面也拿不到实际内容。
• 正确存储认证凭证：如果用JWT，优先存在HttpOnly Cookie里，这样前端JS无法读取，能有效防止XSS攻击窃取凭证；如果必须存在前端，也要做好XSS防护，避免凭证泄露。Apollo里可以通过请求context自动携带凭证，不用把凭证或认证状态存在缓存里。
• 前端状态仅做提示：你依然可以在Apollo缓存里存isAuthenticated，用来控制导航栏显示登录/退出按钮、前端路由跳转的提示性判断，但一定要记住：这个状态只是给用户看的“界面状态”，不是“权限凭证”。比如用户直接输入需要认证的页面URL，前端路由守卫可以先跳转到登录页，但后端在返回该页面的内容时，也要再次验证用户权限，没有权限就重定向到登录页。
• 定期同步真实状态：在页面初始化、用户切换标签页或者执行关键操作时，发起一个后端接口请求，验证用户当前的真实认证状态，然后更新前端的isAuthenticated。这样就算用户篡改了前端状态，也会被同步回真实值。

总结 #

用Apollo Link State存储isAuthenticated本身没问题，但绝对不能依赖它来做安全层面的权限控制。前端状态只是交互的辅助，后端的强制验证才是保障安全的核心。

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