我读过关于Firebase的文章，它看起来很适合我想做的事情。我已经阅读了有关身份验证以及如何根据规则授权某些登录用户执行不同操作的信息。很好。
但是，我不确定另一种类型的安全性：如何确保只有我自己的站点（使用客户端 javascript）才能与我的 firebase-backend 通信？我之所以问，是因为 afaik 无法阻止任何人从客户端代码（指向我的特定 firebase 后端的 url）中查找我的 firebase 端点并开始使用它，因为天知道是什么。
在我想向匿名用户角色开放写入的情况下，这尤其令人担忧。（例如：一些分析也许）
非常感谢任何有助于清除我的想法的帮助。
更新（2021 年 5 月）：借助名为Firebase App Check的新功能，现在实际上可以将对后端服务的调用限制为仅来自在 Firebase 项目中注册的 iOS、Android 和 Web 应用程序的请求。
您通常希望将此与 Kato 在下面描述的基于用户身份验证的安全性结合起来，这样您就有了另一个防护罩，可以防止滥用您的应用程序的用户。
在我看来，这与其说是关于 Firebase 安全性的问题，不如说是对当今互联网架构的一般性讨论。由于网络是一个开放平台，因此您无法阻止任何人访问 URL（包括访问您的 Firebase），就像您无法阻止有人在现实世界中开车经过您的房子一样。如果可以的话，访问者仍然可以对原产地撒谎，而且也没有办法阻止这种情况。
通过身份验证保护您的数据。使用 Forge 中的授权域来防止CSRF。制定安全规则以防止用户做他们不应该做的事情。您将使用服务器来阻止的大多数数据写入都可以仅通过安全规则来完成。
这实际上是一般 Firebase 和 API 服务的优良品质之一。客户端是完全隔离的，因此很容易替换或扩展。只要你能证明你被允许进入并遵守规则，你从哪里打电话并不重要。
关于匿名访问，如果您可以让他们仅从您的站点访问，那仍然不会阻止恶意写入（我可以打开我的 JavaScript 调试器并在您的站点上随意编写任意次数）。相反，对匿名用户可写入的数据的格式、内容和长度设置严格的安全规则，或者为自己节省一些时间并找到一个现有的服务来为您处理您的分析，例如无处不在的 Google Analytics。
当然，您可以像使用任何数据存储一样使用服务器作为中介。这对于某些无法由安全规则强制执行或无法信任经过身份验证的用户（如高级游戏机制）的高级逻辑非常有用。但是，即使您将 Firebase（或任何数据库或服务）隐藏在服务器后面以防止访问，服务器仍将具有 API，并且仍然面临识别客户端来源的所有相同挑战，只要它在网络上。
匿名访问的另一种选择是使用自定义登录，这将允许服务器创建自己的 Firebase 访问令牌（用户不必为此进行身份验证；令牌的签名完全取决于您）。这是有利的，因为如果匿名用户行为不端，则可以撤销访问令牌（通过在 Firebase中存储一个值，安全规则使用该值来强制访问）。
更新
Firebase 现在在简单登录中内置了匿名身份验证，这里的常见用例无需使用自定义登录。