[zmxz]

A web server (nginx) that can proxy your request to the other domain, but your browser sends everything to one domain, thus avoiding CORS.

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.

[rojer_31]

Scenario: In production where assuming ui.example.com is only for static resources/SSG and api.example.com is for dynamic api endpoints, we usually protect the api domain with WAF in CDN which will cost extra and typically unnecessary for the UI domain. So in this case by doing this reverse proxy, we will bypass the WAF layer or atleast feed WAF incorrect data (our server is requesting instead of the user directly). Since WAF usually has extra (significant) costs, what would you suggest in this case?

[zmxz]

Forward the correct data, then it makes no difference to WAF if it's you or user requesting.

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.