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