非getServerSideProps的Next.js客户端axios带Bearer Token安全吗会暴露？

首先明确核心前提：只要是在浏览器客户端执行的请求逻辑，不管是不是Next.js页面、有没有放在getServerSideProps里，只要最终发请求的动作是客户端完成的，不存在完全的“不可观测”，但要分清楚暴露的对象到底是谁，和真正的安全风险是什么。

• 不存在跨用户的公开暴露：每个用户的浏览器运行上下文是完全隔离的，你在当前用户的axios请求里塞的Authorization Bearer token，是这个用户登录后专属的访问凭证，永远不会出现在其他访客的浏览器里，其他用户不可能通过打开你的页面看到这个token。
• 用户自身的可观测是正常现象：当前用户可以通过浏览器开发者工具的网络面板，看到自己发出去的所有请求头，这是浏览器的基础调试能力，不属于意外泄露的范畴。
• 真正的泄露风险来自上下文内的恶意代码：如果页面嵌入了有安全漏洞的第三方JS脚本、被XSS攻击注入了恶意代码，这些脚本可以在当前用户的浏览器上下文里读取所有可访问的内容，不管你的token是存在本地存储里、还是临时塞在请求头里，都能被这些恶意代码窃取。

• 和其他客户端端的鉴权方案比，把access token通过axios附加到Authorization头里，本身没有额外的安全短板：不管你是手动读本地存储里的token拼到请求头，还是让浏览器通过cookie自动带凭证，只要前端JS能触达的内容，恶意脚本都能触达，不存在“塞在请求头就比放cookie里更危险”的区别。
• 要注意的安全边界划分：
  • 如果是权限高、有效期长的access token，不要存在前端JS可读取的位置，换成带HttpOnly、Secure、SameSite属性的cookie，由浏览器自动携带凭证，前端JS完全无法读取到token内容，才能从根源上避免恶意脚本窃取。
  • 如果是短期有效的access token（比如10-15分钟过期），就算被恶意脚本窃取，攻击者可利用的时间窗口极短，配合服务端的设备校验、风控规则，这种在客户端逻辑里通过axios附加Bearer头的方案，是业界通用的可接受实现，没有原则性的安全问题。
• 不要对getServerSideProps的安全作用有误解：哪怕你把请求逻辑放到服务端执行的getServerSideProps里，如果最终把服务端拿到的token传回给客户端的业务逻辑用，本质上还是绕不开客户端的暴露风险，和直接在客户端请求里加头没有区别。

• 不要把“用户能在DevTools看到自己的请求凭证”等同于“token被公开暴露”：这是用户对自己本地运行内容的正常查看权限，不是安全漏洞。
• 不存在“请求头里的内容比页面其他地方的内容更容易被爬取”的问题：前端打包的静态资源里的所有内容，本来就是对当前访客公开的，只要是浏览器能加载的JS，访客都能下载下来看，这点和请求头里的内容没有本质区别。

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