在火力地堡web应用指南规定我应该把给定的apiKey在我的HTML初始化火力地堡：
// 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每个访问者都可以看到。
该密钥的目的是什么，它真的意味着要公开吗？
在apiKey这个配置片段只是标识了谷歌服务器上的火力地堡项目。有人知道它不是安全风险。事实上，他们有必要了解这一点，以便他们与您的 Firebase 项目进行交互。每个使用 Firebase 作为后端的 iOS 和 Android 应用程序中也包含相同的配置数据。
从这个意义上说，它与在同一片段中标识与您的项目关联的后端数据库的数据库 URL 非常相似：https://<app-id>.firebaseio.com. 请参阅有关为什么这不是安全风险的问题：如何限制 Firebase 数据修改？，包括使用 Firebase 的服务器端安全规则来确保只有经过授权的用户才能访问后端服务。
如果您想了解如何确保对 Firebase 后端服务的所有数据访问均获得授权，请阅读有关Firebase 安全规则的文档。这些规则控制对文件存储和数据库的访问，并在 Firebase 服务器上强制执行。因此，无论是您的代码，还是使用您配置数据的其他人的代码，它都只能执行安全规则允许的操作。
有关 Firebase 将这些值用于什么目的以及您可以为其中哪些设置配额的另一说明，请参阅有关使用和管理 API 密钥的 Firebase 文档。
如果您想降低将此配置数据提交给版本控制的风险，请考虑使用Firebase Hosting的SDK 自动配置。虽然密钥仍会以相同的格式出现在浏览器中，但它们将不再被硬编码到您的代码中。
更新（2021 年 5 月）：借助名为Firebase App Check的新功能，现在实际上可以将 Firebase 项目中后端服务的访问权限限制为仅来自在该特定项目中注册的 iOS、Android 和 Web 应用程序的访问.
通常你会想这与上述基于安全的用户认证相结合，让你有针对滥用用户的另一屏蔽部不使用你的应用程序。
通过将 App Check 与安全规则相结合，您既可以广泛地防止滥用，又可以很好地控制每个用户可以访问的数据，同时仍然允许从客户端应用程序代码直接访问数据库。
建立在prufrofro和弗兰克面包车Puffelen的答案在这里，我放在一起这个设置并不妨碍刮，但可以让它稍硬使用您的API密钥。
警告：要获取数据，即使使用这种方法，您也可以简单地在 Chrome 中打开 JS 控制台并输入：
firebase.database().ref("/get/all/the/data").once("value", function (data) {
console.log(data.val());
});
只有数据库安全规则才能保护您的数据。
尽管如此，我将我的生产 API 密钥的使用限制为我的域名，如下所示：
projectname.firebaseapp.com/*）现在该应用程序将仅适用于该特定域名。所以我创建了另一个 API 密钥，它将是本地主机开发的私有密钥。
默认情况下，正如 Emmanuel Campos 所提到的，Firebase 仅白名单localhost和您的 Firebase 托管域。
为了确保我不会错误地发布错误的 API 密钥，我使用以下方法之一在生产中自动使用更受限制的一个。
Create-React-App 的设置
在/env.development：
REACT_APP_API_KEY=###dev-key###
在/env.production：
REACT_APP_API_KEY=###public-key###
在 /src/index.js
const firebaseConfig = {
apiKey: process.env.REACT_APP_API_KEY,
// ...
};
我不相信向客户端公开安全/配置密钥。我不会称之为安全，不是因为有人可以从第一天起窃取所有私人信息，因为有人可以提出过多的请求，耗尽你的配额，让你欠谷歌很多钱。
您需要考虑许多概念，包括限制人们不要访问他们不应该去的地方、DOS 攻击等。
我更希望客户端首先访问您的 Web 服务器，在那里您可以在客户端和服务器之间或服务器和 Firebase 之间放置第一手防火墙、验证码、cloudflare、自定义安全性，然后就可以了。至少您可以先停止可疑活动，然后再到达火力基地。您将拥有更大的灵活性。
我只看到一种使用基于客户端的配置进行内部使用的良好使用场景。例如，您有内部域，并且您很确定外部人员无法访问那里，因此您可以设置浏览器-> firebase 类型等环境。
当启用用户/密码注册时，API 密钥暴露会产生一个漏洞。有一个开放的 API 端点，它接受 API 密钥并允许任何人创建一个新的用户帐户。然后，他们可以使用这个新帐户登录受 Firebase 身份验证保护的应用程序，或使用 SDK 使用用户/密码进行身份验证并运行查询。
我已经向谷歌报告了这个，但他们说它按预期工作。
如果您不能禁用用户/密码帐户，您应该执行以下操作： 创建一个云功能以在创建时自动禁用新用户并创建一个新的数据库条目来管理他们的访问。
例如：MyUsers/{userId}/Access: 0
exports.addUser = functions.auth.user().onCreate(onAddUser);
exports.deleteUser = functions.auth.user().onDelete(onDeleteUser);
更新您的规则，只允许访问权限大于 1 的用户读取。
如果侦听器功能没有足够快地禁用帐户，则读取规则将阻止它们读取任何数据。
我相信一旦数据库规则写得准确，就足以保护您的数据。此外，还可以遵循一些准则来相应地构建您的数据库。比如在users下创建一个UID节点，把所有的信息放在它下面。之后，您将需要实现一个简单的数据库规则，如下所示
"rules": {
"users": {
"$uid": {
".read": "auth != null && auth.uid == $uid",
".write": "auth != null && auth.uid == $uid"
}
}
}
}
其他用户将无法读取其他用户的数据，而且域策略将限制来自其他域的请求。人们可以在Firebase 安全规则上阅读更多相关信息