通过环境变量向Next.js应用暴露密钥是否安全？

你的基础认知是准确的：所有带NEXT_PUBLIC_前缀的环境变量，会在Next.js构建阶段被直接替换为明文值，打包进面向用户下发的客户端JS资源中。

核心问题答复 #

• 用这类变量存储API密钥、OAuth密钥等敏感信息绝对不安全。
• 终端用户完全可以拿到这些涉密值：打开浏览器开发者工具的Sources面板检索静态JS文件、在控制台打印对应变量、抓包解析加载的JS资源都能直接读到明文。哪怕你做了代码混淆，也只是提高了一点提取门槛，对有基础前端知识的人来说形同虚设，现在甚至有成熟的自动化工具专门爬取公开站点JS包里泄露的密钥，几分钟就能扫完一个站点的所有静态资源。
• 规避该风险的推荐方案：
  • 所有敏感凭证（API密钥、OAuth client_secret、数据库连接串、内部服务鉴权token等）一律不要加NEXT_PUBLIC_前缀。不带此前缀的环境变量只会在服务端运行时生效，永远不会被打包进客户端代码，用户根本接触不到。
  • 客户端需要调用带鉴权的第三方接口时，不要直接从浏览器侧发起请求，自己加一层服务端代理：
    • 用App Router就写Route Handler，用Pages Router就写API Routes
    • 客户端只请求你自己的这层服务端接口，由服务端携带真实密钥去请求第三方服务，拿到结果再返回给客户端
    • 整个流程里密钥全程只在服务端流转，根本不会暴露给公网用户
  • OAuth等授权流程中，所有需要用到密钥的环节（比如授权码换access_token、请求签名校验）全部放到服务端执行，客户端仅能存放不需要保密的公开参数（比如公开类型的OAuth client_id）。
  • 如果你之前误将敏感信息配置为NEXT_PUBLIC_变量且已经上线，第一时间到对应服务提供方处轮换所有泄露的密钥，别抱着“没人会特意扒我网站”的侥幸，这类密钥泄露被黑产自动化爬取拿去盗刷的案例非常多。

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