It's an extremely common scenario. The obvious and straightforward solution is to configure path-based cache rules exactly like you describe, to proxy requests which don't correspond to static assets. Cloudfront allows you to do this out of the box, as do other major CDN providers. If your CDN doesn't support this, consider switching - or introduce an edge proxy to facilitate it.

We use Fastly (the Hosts feature) to do exactly this. Basically it routes requests to different backends based on the URL path. If it starts with /assets, the backend is S3. If it starts with /api, the backend is our application. If it starts with /blog, the backend is Wordpress. All on different hosting platforms.

(In case it’s not clear, Fastly is also caching and serving these requests as a CDN.)

So that would indicate that you don't do end-to-end TLS on your infrastructure for the API which means that Fastly man-in-the-middles your API.

In a lot of sensitive businesses that wouldn't be allowed.

Are you sure about that? Have you talked to a good lawyer about it?

This is not necessarily only a legal issue it's also an information security issue.

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.

Unless you are terminating TLS entirely on owned hardware, you are paying a 3rd party to manage TLS for you.

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.

You're putting a lot of trust in your CDN, anyway. If your CDN gets hacked, what's stopping your frontend code from being updated to send your API requests somewhere else? Maybe they get rerouted to a proxy, then back to you...

Serving said JS on CDN implies that the JS performs xhr/fetch, which means I have control over said CDN

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

> you want to serve your API from the same origin as your static files (HTML, CSS, JS, etc.)

What is the benefit or purpose of doing this?

You don't have CORS configuration to worry about. It simplifies development and deployment.

You don't need to set up CORS to load assets on a page from a CDN's origin. Cross-origin taint only matters when trying to read asset data from a script.

I think we may be talking past each other and one of us is misunderstanding OP.

Yes, but you need it if your API isn't on the same origin as your static assets.