我已经在我的firebase应用程序上实现了"twitter身份验证"。如下所述：https://www.firebase.com/docs/web/guide/login/twitter.html
它工作得很好。
一旦用户登录，他还可以使用XMLHttpRequest向我的域发送一些请求。
当我发送XMLHttpRequest的有效负载时，我倾向于通过javascript传递"用户名"。
我刚刚意识到，一个使用"Chrome开发工具"的人可以拦截并篡改我的用户名。
我有办法解决这个问题吗？
=================================================
示例：想象一下，我的网站在这里运行：
www.example.com/
它提供一个带有大量javascript的静态页面index.html该页面使用firebaseapi，并允许人们通过twitter（或github）进行身份验证。现在让我们假设一个人（已经登录）想要发布一些内容。我目前是这样执行的：https://www.example.com/writeComment?comment=hello&username=jeff&provider=github
我担心的是，登录并不能让我免受一个摆弄Chrome控制台并更改用户名的人的伤害。
没有问题需要解决。这没什么错。除非您在客户端和API之间来回发送受保护的数据，否则您需要SSL。
请记住，客户端完全由启用CORS的API驱动现在已成为规范。安全地处理数据取决于实施团队。
在Firebase服务本身的上下文中：
Firebase为您处理许多其他安全细节。具体来说，我们为SSL证书使用强2048位密钥，使用SHA256 HMAC签名对身份验证令牌进行签名，并使用BCrypt进行密码存储。
https://www.firebase.com/docs/security/quickstart.html
如果我正确理解这个问题，那么您有两个服务客户端连接到：Firebase和您管理的后端服务器。
您的后端服务器当然不应该信任用户发送的任何内容，即使它是通过HTTPS传递的。一个简单的答案是向服务器发送auth令牌，并让它使用它来验证用户（因为令牌不能伪造）。
一个更优雅的解决方案是省去绕过Firebase并连接到RESTneneneba API的整个过程。相反，使用队列策略并让客户端写入Firebase。
有了安全规则，服务器就不再需要担心身份验证了。如果用户可以写入一个安全的路径，那么他们已经通过了身份验证，问题就解决了。然后，服务器可以处理排队的请求，并以安全的方式通过写回Firebase进行响应。
这样一来，就没有RESTneneneba API需要维护，没有双重身份验证，也没有开销。只要让Firebase成为权威，并将所有其他流程——特权或客户——变成消费者。