如果规则是在应用程序代码本身中实现的，并且与数据库中的数据子项相比，为什么我们还需要安全规则？
案例示例：群聊主持人可以踢出用户。我们怎么知道他是主持人并且可以将他们踢出去？好吧，通过添加一个孩子，它指定他是群聊的主持人，并确保所有群聊成员都知道该数据。 （可能是他唯一的“displayName”作为键“Host”的值）
从上面的案例示例中，为什么要为此添加安全规则？应用程序与数据库“主机”子级通信时已经使用了“逻辑”规则。
我对安全规则相当陌生。我做了一些阅读，但没有回答我的问题。如果这里有什么明显的地方，我深表歉意。
【问题讨论】：
标签： firebase firebase-realtime-database firebase-security
在传统的three-tier architecture 中，您将在服务器上实现应用程序逻辑，您可以放心，这是您 编写的用于访问数据库的代码。但是，当使用后端即服务时，您只有两层：客户端应用程序代码直接访问数据库。
为了允许应用直接与数据库通信，访问 Firebase 项目所需的配置数据保存在应用本身中。但这也意味着恶意用户可以从您的应用中复制配置数据，并使用他们的代码对您的项目进行API调用。
如果您不实施安全规则，恶意用户可以（因此会）对您的数据做任何他们想做的事情，包括读取整个数据库，并可能覆盖部分或全部数据。实际上只需要几行 JavaScript 代码就可以对未受保护的数据库造成严重破坏。
在这个两层系统中，数据库的安全规则充当其服务器端应用程序逻辑。它们强制执行您要应用于数据库的规则，没有人可以使用客户端 SDK 绕过它们。
由于您不熟悉使用安全规则，我强烈建议您查看此 documentation page 上的视频。
您通常希望将安全规则与新的 Firebase 应用检查功能结合起来，以减少广泛的滥用并进行细粒度的访问控制。
【讨论】：