有没有办法保护 Firebase 云函数在未经用户身份验证的情况下被入侵者调用？

Question

I'm using Firestore as a database for my website to store my data. I'd like to use Firebase cloud functions to use the cache, in order to limit my reading requests which are limited to 50000 per day.

The fact is, my users don't need to be authenticated to fetch some basic datas, and I'd like to know if you could figure out a way to proceed endpoint calls from only authorized application.

So far I've been thinking of creating my own "secret key" to pass as a parameter in my request and this is the only solution I found on the subject, but I know this isnt a real security as far as you can see the body of the request in the console. The only other solutions I found on the web would be to make sure users are authenticated to check their token, but I don't want to force them to get logged in to use my website.

I'm kind of disappointed that there are no clear ways to identify my application as a trusted one through firebase ecosystem... If you have any clue, it would be very helpfull.

Answer 1

It's not possible to fully protect an HTTP function to be called from just your app. Here's why:

1. Client devices should be considered compromised and under full control of a malicious user. As such, you can't trust any code on them, even if it came with your own app.
2. If you can't trust the code, then can't trust any information held in memory by that code.
3. If you can't trust what's in memory, then you can't trust anything passed to your backend. This means you really have no way of protecting it from malicious use at all.

Cloud Functions doesn't offer any solutions here, because there are no 100% bulletproof solutions that can be deployed with application code that sits on a user's device. What you're doing now might be "good enough" to prevent casual hacking, but bear in mind that anyone could get a hold of that token for the purpose of spoofing calls, and you'd never know that was happening.

This is why developers use Firebase Auth or some other auth mechanism, as a way to have an independent source verify the identity of the end user that can't be compromised by malicious client code, or at least not for more than 1 hour after an ID token is leaked.