Javascript中敏感信息隐藏方法及API密钥处理最佳实践

一、你提到的凭证是否属于敏感信息？ #

你给出的两个示例里的公开凭证本身不属于高敏感的核心密钥，都是服务商专门设计用于前端公开使用的：

• Firebase配置里的apiKey本质是项目唯一标识符，作用是让前端SDK关联到对应的Firebase项目，官方明确允许公开在前端代码中。
• Pusher构造函数里的第一个参数是App公钥，仅用于前端初始化连接，私有操作的鉴权需要后端配合使用独立的密钥，这个公钥本身设计为可公开。

但要特别注意：这只是特例，如果你把后端接口密钥、数据库密码、管理员权限Token这类仅服务端可持有信息写在前端，属于严重的敏感信息泄露，会直接导致资源被盗用、服务被攻击。
就算是上述可公开的凭证，没有做好配套权限控制也会带来风险：比如Firebase没有配置安全规则的话，任何人拿到你的项目配置都可以读写你的数据库、消耗你的存储流量资源。

二、这类问题的最佳实践 #

• 明确区分密钥类型：仅将服务商明确说明允许客户端公开的公钥/客户端标识放到前端代码中，所有需要权限调用的服务端密钥、私有凭证必须全部存储在服务端，绝对不能出现在前端静态资源里。
• 配置严格的权限规则：
  • 用Firebase必须为Storage、Firestore、实时数据库配置对应安全规则，比如仅登录用户可操作自己的私有数据，未授权用户没有操作权限，从规则层面杜绝凭证被滥用的可能。
  • 用Pusher处理私有消息时，必须走服务端做订阅权限校验，不要直接在前端订阅公开频道传输敏感数据。
• 避免硬编码凭证：无论前端后端，所有凭证都通过环境变量注入，不要直接写在代码中提交到代码仓库，避免仓库泄露导致凭证流出。
• 私有接口走后端转发：如果需要调用的第三方API没有提供客户端专用公钥，不要直接在前端调用，统一由后端做中转：前端请求你的后端接口，后端携带密钥请求第三方服务，再将结果返回给前端，完全把第三方密钥隔离在服务端。

三、Linode页面源码极少的实现逻辑 #

这是单页应用（SPA）的标准打包效果：

1. 所有业务逻辑、页面代码、配置信息都会通过Webpack、Vite这类打包工具进行压缩、混淆、合并，最终生成独立的JS资源包，也就是你看到的/static/js/main.339b6f48.js，HTML文件仅保留最基础的骨架代码，不会直接嵌入业务逻辑和配置。
2. 这类内部管理系统的敏感配置不会提前打包到前端静态资源中，需要时会通过接口从后端动态获取，同时会做登录权限校验，未登录的用户无法获取到相关敏感配置。
3. 部分应用还会做代码拆分，不同权限的用户只能加载对应权限的代码块，进一步避免敏感信息泄露。

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