Supabase+Next.js服务端认证下仍出现客户端Cookie的疑问

1. 登录后可见客户端Cookie是否存在XSS风险？ #

得看这些Cookie的类型和属性：

• 如果是refresh token这类敏感认证凭证且没设HttpOnly，那肯定有XSS风险——恶意脚本能直接读取并窃取，进而冒充用户会话。
• 如果是短期有效的access token或者非敏感的辅助Cookie，风险相对可控，但前提是服务端验证身份时，是从服务端托管的HttpOnly Cookie里读取凭证，而非依赖客户端提交的token。

建议直接在浏览器DevTools里检查Cookie的HttpOnly、Secure标记：核心的sb-refresh-token必须是HttpOnly+Secure，要是没设置，那就是配置漏洞。

2. 服务端认证的核心是不是完全不依赖客户端Cookie？ #

不是，服务端认证的核心是敏感认证逻辑在服务端执行，且敏感凭证（比如refresh token）通过HttpOnly Cookie存储——浏览器自动携带，客户端JS无法读取，而非完全不用客户端Cookie。

Supabase的服务端方案就是这个逻辑：你用createServerClient在服务端处理认证，从请求的Cookie里取凭证，客户端不用碰敏感token，也读不到HttpOnly的refresh token。你看到的客户端Cookie，要么是Supabase为兼容客户端操作（比如实时订阅）设的非敏感凭证，要么是你不小心同时用了客户端的createBrowserClient导致的。

3. Supabase为啥不给服务端Cookie设HttpOnly？ #

先澄清：Supabase服务端Cookie认证的核心refresh token Cookie默认是带HttpOnly属性的。你看到无HttpOnly的Cookie，大概率是以下情况：

• 你同时启用了客户端认证模式（比如调用了createBrowserClient），这时候客户端会生成非HttpOnly的access token Cookie，供客户端JS使用。
• 你手动修改了cookieOptions，关闭了httpOnly配置。
• 某些场景下（比如实时订阅），Supabase需要客户端JS拿到access token，所以会设非HttpOnly的Cookie，但这类token有效期短，且服务端验证时不会只认客户端提交的这个值。

如果核心的refresh token Cookie确实没HttpOnly，那肯定是配置错了，检查你的createServerClient配置，确保开启了服务端Cookie模式，没覆盖默认的Cookie属性。

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