仅用原生HTML/CSS/JS的公开GitHub Pages项目如何隐藏Firebase密钥

很多人对Firebase的前端配置存在根本性误解：

• 你在Firebase控制台获取的apiKey、authDomain这类连接配置，从设计层面就是为浏览器端运行场景设计的，不存在“完全隐藏不被用户看到”的可能——哪怕你套了代理、做了代码混淆，最终要连接数据库的逻辑还是要在浏览器端执行，硬要把这个配置藏起来本质是违背产品设计逻辑的。
• 真正的安全风险从来不是配置本身被看到，而是没配置Firestore安全规则，把数据库设成了无权限校验的全开放状态。只要把规则护栏搭好，哪怕配置被所有人看到，也不会有数据泄露、被恶意篡改的风险。

整个流程不需要引入任何构建工具、不需要后端服务，完全靠原生HTML/CSS/JS就能跑通：

第一步：优先搭好安全护栏（重要性远高于“藏密钥”） #

• 进入Firebase控制台的Firestore规则配置页，关掉默认的全开放读写权限，配置成“仅允许已完成匿名认证的用户操作数据库”，拒绝所有未认证的请求。
• 可直接复用的基础规则示例：

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      // 仅允许完成Firebase匿名认证的用户读写数据
      allow read, write: if request.auth != null;
    }
  }
}

• 配置完成后，就算有人拿到你的前端连接配置，没有走你页面的匿名认证流程，根本无法连接你的数据库，更不能随意修改、删除你的数据。

第二步：做好配置隔离，避免误提交高敏感凭证 #

• 绝对不要把带管理员权限的Firebase Admin SDK私钥、服务账户凭证这类真·敏感文件放到前端项目目录里，这类内容一旦提交到公开仓库会直接带来数据安全风险。你前端只需要用面向浏览器的基础Web连接配置就足够实现功能。
• 把存了本地开发配置的firebase.config.js文件加入.gitignore忽略列表，不要把本地开发用的配置提交到公开仓库。
• 针对GitHub Pages的演示场景，可以单独新建一个临时的Firebase演示实例，专门用来给老师批改作业时展示。等作业提交完成、批改结束后，直接删掉这个演示实例即可，没有长期维护的成本。

第三步：纯原生实现连接逻辑，完全不引入框架 #

• 直接通过原生script标签引入Firebase的JS SDK，不需要npm、不需要打包工具，和引入普通原生JS文件没有区别：

<script src="https://www.gstatic.com/firebasejs/10.12.2/firebase-app-compat.js"></script>
<script src="https://www.gstatic.com/firebasejs/10.12.2/firebase-firestore-compat.js"></script>
<script src="https://www.gstatic.com/firebasejs/10.12.2/firebase-auth-compat.js"></script>

• 写初始化逻辑的时候，不要把演示用的配置硬编码进长期提交的JS文件里，可以加一个简单的判断逻辑：只有当全局存在演示用的配置对象时，才初始化Firebase连接，否则就提示“当前环境未开启数据库演示功能”。部署演示版本时，临时把演示实例的配置嵌进去推送到GitHub Pages就行，等演示结束再把这个临时配置删掉，换回占位的静态逻辑。

• 不要为了“藏住前端配置”硬搭后端、上打包工具，这类操作完全违反你作业要求的“纯原生实现、纯静态GitHub Pages部署”的规则，而且完全没必要——你费劲藏的配置本来就不是需要严格保密的敏感信息。
• 不要轻信网上“用.env文件就能藏住前端密钥”的教程，所有最终跑在浏览器里的JS代码，不管怎么混淆、怎么打包，都会被浏览器解析成明文，按F12就能看到全部内容，靠“藏”根本实现不了真正的安全。
• 前端的安全边界从来不是靠“隐藏代码”实现的，是靠服务端的权限规则把访问边界划清楚。就像你家的安全不是靠把门牌号码藏起来实现的，是靠门锁的权限校验，哪怕别人知道你家地址，没有钥匙也进不来。

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