There's 1 way to solve this, and it's to have the same domain that the end client (browser, app) uses. It means you'd create 1 domain that's exposed to client and on the web server level you perform routing (proxying) to appropriate firebase/cloud run domains.

As for whether that's easier - I've been doing it like this since forever, so I'm biased and it's easy for me. It's easy because I don't have to worry about problems related to cross origin resource sharing and because I know how to write the necessary configs. If you don't have to walk through mine field, you never worry about mines. That's the easy part I refer to. I don't even need to test whether CORS is set up properly, worry about preflight and what not etc. - it works, forever.

Whether it will be as easy for you, I can't tell that, you can have completely different opinion and be correct about it, but the fact remains that proxy between 2 resources removes the problem. I consider problem removed as something easy, you might not.

It's would argue its all about just not throwing a bunch of buckets and rakes on the floor during the networking design-phase that your entire dev, qa and then dev ops teams will proceed to walk into in every other stage that follows.

If you're dealing with a bunch of separate black boxes (as our firebase poster is) then maybe you do have to wrangle CORS but if you're developing your own applications then there is no good reason to introduce these issues into your pipeline.

Somehow, I think putting a proxy in front of Firebase is not the right solution here at all. The same goes when the website is served by any other CDN. Great, we have this thing that can serve nearly infinite number of requests has DDOS protection and is always close to the customer, let's put a proxy in front of it because we don't know how to setup CORS.

CORS ain't that hard.

Why put anything in front of Firebase hosting? Why not use Firebase hosting as the front?

This confirms my initial comment - people making up reasons.

The solution is always the same, it's always as easy and there's never the need to introduce something new since you can use what you already have.

> on the web server level

Does that mean that I'd have to introduce a web server in front of Firebase Hosting that I'd have to maintain and scale, not to mention that it negates all advantages of using FB hosting in the first place?

I'll stick with CORS, thank you.

You're jumping to conclusion too fast. You already have the web server and you can already achieve no-CORS without "introducing" anything new. I'm not trying to convince you, but since you're someone who works in this field - you're drawing wrong conclusions. Stick to what you know, sooner or later you'll realize that CORS is not as simple and as benign as it may seem.

There's a comment below mine that tells you you can achieve this kind of proxy with the actual Firebase itself. And your comment, again, proves my hypothesis - people just make reasons up with improper arguments.

I've worked with Firebase Hosting for around three years, using Firebase Functions instead of Cloud Run, but in your particular example, you can configure your Firebase Hosting to rewrite requests against your Cloud Run instances as documented in https://firebase.google.com/docs/hosting/full-config#rewrite....

This doesn't require handling an OPTIONS request for every endpoint, which I agree could be fairly simple, but Firebase Hosting configuration could very well be less invasive than this change in the rest of the codebase.

Thanks a lot, I'll have a look into this.