Конечно может, и не только может, но и должно. Единственная проблема, которая остается — ориджин домен. Который и решается за счет хостс файла либо записи в другом днс. Но, используя Ваши же слова, что все это может значить для фронтенда, если есть бэкенд, который «должен вотэтовотвсе», в т.ч. настроить локальное место разработчика-фронта?)
Мы ведь только что решили, что порты решаются за счет проксирования, не ?) proxy.conf.json у ангулара, уверен, что у других фреймоворков есть аналоги.
При чем тут порты к корс ?) Порты — чисто проблема проксирования. Оба локально == на одном домене по определению. Корс — проблема разных доменов.
Но ведь это уже не проблема корс)
В этой ситуации важно лишь то, чтобы и фронт и апи сервились с одного домена. Поэтому, если у него апи отвечает на api.domain.com, то записи front.domain.com в хостс более, чем достаточно. Если его и апи, и фронт, развернуты локально, то и разницы в доменах нет, соотв. и необходимости в корс.
Во-первых, как уже ниже говорили, между бэкендом и фронтендом чаще всего не один слой других серверов. Если ваш фронт обращается напрямую к бэкенд серверу — это вот вообще не очень. Именно эти промежуточные уровни должны разбираться в CORS, гзипах, лоадбалансерах итд. И именно это, чаще всего, бэкенду как раз совсем не интересно.
Во-вторых, исходя коментов ТСа ниже, конкретная проблема заключается в том, что он со своего локалхоста не может достучаться до апи-сервера. Если я это правильно понял, то тогда перед пинанием бэков за непонимание CORS, ему бы стоило попробовать прописать в хостс файле 127.0.0.1 mycoolapp.domain.com и забыть про эту ситуацию.
Ждём новых откровений, как этот зловредный монобанк даст списать деньги с украденного телефона по отрезанному пальцу не сверяя дайнэмик цвв!