Firebase Web-App指南指出，我应该把给定的apiKey放在我的Html来初始化Firebase:
// TODO: Replace with your project's customized code snippet
<script src="https://www.gstatic.com/firebasejs/3.0.2/firebase.js"></script>
<script>
// Initialize Firebase
var config = {
apiKey: '<your-api-key>',
authDomain: '<your-auth-domain>',
databaseURL: '<your-database-url>',
storageBucket: '<your-storage-bucket>'
};
firebase.initializeApp(config);
</script>
这样，apiKey就暴露给了每个访问者。
这个密钥的目的是什么?它真的是要公开的吗?
当前回答
我正在github页面上做一个博客网站。我有一个想法，在每个博客页面的末尾嵌入评论。我知道firebase是如何获取和提供数据的。
我已经用项目甚至控制台测试了很多次。我完全不同意vlit是脆弱的这句话。 相信我，如果你遵循了firebase建议的隐私保护步骤，公开显示你的api密钥是没有问题的。 访问https://console.developers.google.com/apis 而且还是从安保部门来的。
其他回答
包含它们是可以的，只有在Firebase ML或使用Firebase身份验证时才需要特别注意
Firebase的API密钥与典型的API密钥不同: 与API密钥的典型使用方式不同，Firebase服务的API密钥不用于控制对后端资源的访问;这只能通过Firebase安全规则来实现。通常，您需要严格地保护API密钥(例如，通过使用保险库服务或将密钥设置为环境变量);但是，Firebase服务的API密钥可以包含在代码或签入配置文件中。
尽管在代码中包含Firebase服务的API密钥是安全的，但在某些特定情况下，您应该强制限制API密钥;例如，如果您正在使用Firebase ML或使用带有电子邮件/密码登录方法的Firebase身份验证。稍后在本页了解更多有关这些案例的信息。
欲了解更多信息，请查看官方文档
这个配置片段中的apiKey仅标识谷歌服务器上的Firebase项目。让别人知道它不会有安全风险。事实上，为了让他们与您的Firebase项目进行交互，让他们知道这一点是必要的。同样的配置数据也包含在所有使用Firebase作为后端的iOS和Android应用程序中。
从这个意义上说，它非常类似于在同一代码段中标识与项目关联的后端数据库的数据库URL: https://<app-id>.firebaseio.com。请参阅以下问题，了解为什么这不是安全风险:如何限制Firebase数据修改?，包括使用Firebase的服务器端安全规则，以确保只有授权用户才能访问后端服务。
如果您想了解如何确保对Firebase后端服务的所有数据访问是授权的，请阅读有关Firebase安全规则的文档。这些规则控制对文件存储和数据库访问的访问，并在Firebase服务器上强制执行。因此，无论使用配置数据的是您的代码，还是其他人的代码，它都只能执行安全规则允许的操作。
有关Firebase使用这些值的另一个解释，以及可以为其中哪些设置配额，请参阅Firebase关于使用和管理API密钥的文档。
如果您希望降低将此配置数据提交给版本控制的风险，请考虑使用Firebase Hosting的SDK自动配置。虽然键在浏览器中仍然以相同的格式显示，但它们不会再硬编码到您的代码中。
更新(2021年5月):多亏了名为Firebase App Check的新功能，现在实际上可以限制对Firebase项目中后端服务的访问，只允许来自特定项目中注册的iOS、Android和Web应用程序。
通常情况下，你需要将其与上面描述的基于用户身份验证的安全性结合起来，这样你就有了另一个盾牌，可以防止滥用你的应用程序的用户。
通过将App Check与安全规则相结合，你既可以广泛地防止滥用，又可以很好地控制每个用户可以访问的数据，同时仍然允许从客户端应用程序代码直接访问数据库。
虽然最初的问题得到了回答(api密钥可以暴露-数据的保护必须从DB规则中设置)，但我也在寻找一种解决方案来限制对DB特定部分的访问。 所以在阅读了这篇文章和一些关于可能性的个人研究之后，我想出了一个稍微不同的方法来限制未经授权的用户使用数据:
我也在我的数据库中保存我的用户，在相同的uid下(并在那里保存配置文件数据)。所以我只是像这样设置db规则:
".read": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()",
".write": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()"
这样，只有以前保存的用户才能在DB中添加新用户，因此没有帐户的人无法对DB进行操作。
此外，只有当用户具有特殊角色并且只能由管理员或该用户自己编辑时，才可以添加新用户(就像这样):
"userdata": {
"$userId": {
".write": "$userId === auth.uid || root.child('/userdata/'+auth.uid+'/userRole').val() === 'superadmin'",
...
我相信，一旦数据库规则被准确地编写出来，就足以保护您的数据。此外，还可以遵循一些指导原则来相应地构建数据库。例如，在用户下创建UID节点，并将所有信息放在该节点下。之后，您需要实现一个简单的数据库规则，如下所示
"rules": {
"users": {
"$uid": {
".read": "auth != null && auth.uid == $uid",
".write": "auth != null && auth.uid == $uid"
}
}
}
}
其他用户将无法读取其他用户的数据，此外，域策略将限制来自其他域的请求。 你可以在上面读到更多 Firebase安全规则
我不相信向客户端公开安全/配置密钥。我不认为它是安全的，不是因为有人可以从第一天开始窃取所有的私人信息，而是因为有人可以提出过多的要求，耗尽你的配额，让你欠谷歌很多钱。
你需要考虑很多概念，比如限制人们访问他们不应该访问的地方，DOS攻击等等。
我更喜欢客户端首先会击中你的web服务器，在那里你把任何第一手的防火墙，验证码，cloudflare，自定义安全在客户端和服务器之间，或服务器和firebase之间，你就好了。至少你可以在可疑活动到达火源之前阻止它。你会有更大的灵活性。
在内部使用基于客户端的配置时，我只看到一个好的使用场景。例如，您有一个内部域，并且您非常确定外部人员无法访问该域，因此您可以设置类似浏览器-> firebase类型的环境。
