Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Firebase cloud function: how to deal with continuous request

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.

like image 918
Lạng Hoàng Avatar asked Nov 01 '17 07:11

Lạng Hoàng


People also ask

How many requests can a cloud function handle?

Cloud Functions scales by creating new instances of your function. Each of these instances can handle only one request at a time, so large spikes in request volume might result in creating many instances.

How long can a Firebase function run?

Time Limits60 minutes for HTTP functions. 10 minutes for event-driven functions.

What is the difference between onCall HTTP callable and onRequest HTTP request functions?

onRequest creates a standard API endpoint, and you'll use whatever methods your client-side code normally uses to make. HTTP requests to interact with them. onCall creates a callable. Once you get used to them, onCall is less effort to write, but you don't have all the flexibility you might be used to.

Are Firebase functions async?

Most of Firebase's APIs are asynchronous. This might be confusing at first: you're making a call, for example to fetch some data from Firestore, but you don't get a result back.


1 Answers

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.

like image 179
johnozbay Avatar answered Sep 24 '22 22:09

johnozbay