3. Don't allow cross-platform requests in the first place; have your API consumers go through a server-side proxy on the same domain instead, or host it on the same domain in the first place.
I'm careful that I don't demand anyone go into depth on any particular subject. CORS is just one opportunity that seems to need a fix with every new project. It also has a variety of solutions, which is again opportunity to show what they know.
There is little point in looking for what a client doesn't know. I've got that covered.
I'd like you to back up your claim that a server-side proxy or using the same domain is the easiest solution, and in particular, easier than the solutions suggested by cakoose.
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.
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.
CORS ain't that hard.
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.
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.
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.
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.
It's a very common case.
Basically that won't work besides making your CDN somehow proxy requests for which not static file exists.
(In case it’s not clear, Fastly is also caching and serving these requests as a CDN.)
In a lot of sensitive businesses that wouldn't be allowed.
You can't guarantee the integrity and privacy of the full request and response chain.
This goes against various security standards and ISOs.
You might be able to get away with it and trust the CDN but that's an awful lot of trust.
A lot of people seem to think that there is a big difference between paying a lessor (e.g. Hetzner) for a server on which you terminate TLS, paying a cloud host (e.g. Amazon) to terminate TLS, and paying a CDN (e.g. Fastly) to terminate TLS. Legally there is no difference aside from the specific language of the contracts, which you can review and negotiate in advance.
The difference security-wise is entirely down to the operations of each company, which again you can review and discuss in advance. Strictly speaking a CDN should have lower risk than a host since they are not persisting sensitive data (if you set your cache headers correctly). And as discussed above, using one domain helps avoids cross-domain security concerns.
Given the fact I have control over domain(s), I'd have http://domain.tld/api for API and serve static js from http://domain.tld/static/*.js
Given the fact I have the need for CDN, it means I've got enough traffic that justifies the bill incurred
What is the benefit or purpose of doing this?
I think we may be talking past each other and one of us is misunderstanding OP.
Say you stand up a website with an API at https://example.com. You host your static assets on the CDN, at https://example.myfastcdn.com/. So example.com's home page looks like:
<head>
<script src="https://example.myfastcdn.com/app.js"></script>
</head>
<body>
<div id="site-root"></div><!-- app.js renders some application here -->
</body>
What am I missing here?
It's like saying that a house built without a lock is a made up issue and that no lock pr door is needed.
Public CDN should never be trusted. If you use a CDN in the first place and have strict security requirements, then you create your own private CDN. And if you can control that private CDN, you have all the ingredients to avoid CORS.
It's really that simple. No one is saying you are wrong, but you're refusing to look at the entire picture and you focus only on a subset, in which - of course - your argument works.
I'm sorry but that's simply not an acceptable constraint.
No one is telling you not to deal with CORS your way. Fact of the matter is that you can avoid it, but you're making up reasons why you can't. The only reason you can't is because you won't. You're free to use whatever approach you like, there's no police here, just don't state that I or anyone else wrote what we didn't. It'd be grown up thing to do. Thanks and best of success with your projects.
Example: you have http://ui.localhost and you have http://api.localhost
UI speaking to API = CORS
But, instead of doing fetch('http://api.localhost/resource'), you do fetch('http://ui.localhost/api/resource')
In the nginx config for ui.localhost domain, you create a rule that says "everything that starts with /api, intercept it, remove /api at the start of the path and send the rest to http://api.localhost, ending up with http://api.localhost/resource"
I do frontend and backend development and I have this setup with docker-compose, the config for nginx is really trivial and widely available in many tutorials.
That's why we have various controls with proxies, such as including the original requester's IP etc.
It's irrelevant who actually asks for data if you pass the HTTP request info unaltered (except path parameter), the WAF can do its job. That's the beauty of HTTP and its stateless nature. You can scale infinitely and do various actions such as this one and get the expected result.
That works for first-party JS. Doesn't work for a public API used by others.
Edit: Specifically purely client-side apps. For someone hosting a static HTML+JS app, it's annoying to have to set up and run a server-side route just to circumvent CORS.
(Maybe not so bad with something like Next.js, where it's easy to add a backend route to your primarily static website.)
And it adds an extra hop of latency to every request.