Firebase cloud function: how to deal with continuous request

Question

When working with Firebase (Firebase cloud function in this case), we have to pay for every byte of bandwidth.

So, i wonder how can we deal with case that someone who somehow find out our endpoint then continuous request intentionally (by a script or tool)?

I did some search on the internet but don't see anything can help. Except for this one but not really useful.

Answer 1

Since you didn't specify which type of request, I'm going to assume that you mean http(s)-triggers on firebase cloud functions.

There are multiple limiters you can put in place to 'reduce' the bandwidth consumed by the request. I'll write a few that comes to my mind

1) Limit the type of requests

If all you need is GET and say for example you don't need PUT you can start off by returning a 403 for those, before you go any further in your cloud function.

if (req.method === 'PUT') { res.status(403).send('Forbidden!'); }

2) Authenticate if you can

Follow Google's example here and allow only authorized users to use your https endpoints. You can simply achieve this by verifying tokens like this SOF answer to this question.

3) Check for origin

You can try checking for the origin of the request before going any further in your cloud function. If I recall correctly, cloud functions give you full access to the HTTP Request/Response objects so you can set the appropriate CORS headers and respond to pre-flight OPTIONS requests.

Experimental Idea 1

You can hypothetically put your functions behind a load balancer / firewall, and relay-trigger them. It would more or less defeat the purpose of cloud functions' scalable nature, but if a form of DoS is a bigger concern for you than scalability, then you could try creating an app engine relay, put it behind a load balancer / firewall and handle the security at that layer.

Experimental Idea 2

You can try using DNS level attack-prevention solutions to your problem by putting something like cloudflare in between. Use a CNAME, and Cloudflare Page Rules to map URLs to your cloud functions. This could hypothetically absorb the impact. Like this :

*function1.mydomain.com/* -> https://us-central1-etc-etc-etc.cloudfunctions.net/function1/$2

Now if you go to

http://function1.mydomain.com/?something=awesome

you can even pass the URL params to your functions. A tactic which I've read about in this medium article during the summer when I needed something similar.

Finally

In an attempt to make the questions on SOF more linked, and help everyone find answers, here's another question I found that's similar in nature. Linking here so that others can find it as well.

Answer 2

Returning a 403 or empty body on non supported methods will not do much for you. Yes you will have less bandwidth wasted but firebase will still bill you for the request, the attacker could just send millions of requests and you still will lose money.

Also authentication is not a solution to this problem. First of all any auth process (create token, verify/validate token) is costly, and again firebase has thought of this and will bill you based on the time it takes for the function to return a response. You cannot afford to use auth to prevent continuous requests.

Plus, a smart attacker would not just go for a req which returns 403. What stops the attacker from hitting the login endpoint a millions times?? And if he provides correct credentials (which he would do if he was smart) you will waste bandwidth by returning a token each time, also if you are re-generating tokens you would waste time on each request which would further hurt your bill.

The idea here is to block this attacker completely (before going to your api functions). What I would do is use cloudflare to proxy my endpoints, and in my api I would define a max_req_limit_per_ip and a time_frame, save each request ip on the db and on each req check if the ip did go over the limit for that given time frame, if so you just use cloudflare api to block that ip at the firewall.

Tip: max_req_limit_per_ip and a time_frame can be custom for different requests.

For example:

1. an ip can hit a 403 10 times in 1 hour
2. an ip can hit the login successfully 5 times in 20 minutes
3. an ip can hit the login unsuccessfully 5 times in 1 hour

Answer 3

There is a solution for this problem where you can verify the https endpoint.

Only users who pass a valid Firebase ID token as a Bearer token in the Authorization header of the HTTP request or in a __session cookie are authorized to use the function.

Checking the ID token is done with an ExpressJs middleware that also passes the decoded ID token in the Express request object.

Check this sample code from firebase.

Answer 4

Putting access-control logic in your function is standard practice for Firebase, BUT the function still has to be invoked to access that logic.

If you don't want your function to fire at all except for authenticated users, you can take advantage of the fact that every Firebase Project is also a Google Cloud Project -- and GCP allows for "private" functions.

You can set project-wide or per-function permissions outside the function(s), so that only authenticated users can cause the function to fire, even if they try to hit the endpoint.

Here's documentation on setting permissions and authenticating users. Note that, as of writing, I believe using this method requires users to use a Google account to authenticate.