Как обойти ошибку CORS, если бекендеры не добавляют origin в whitelist

Что проверяют

Понимаете ли вы, что CORS это защита на стороне браузера: простой запрос доходит до бэкенда, но браузер не отдаёт ответ скрипту. Хороший кандидат разделяет разработку и продакшн и не предлагает «отключить CORS». Следом спрашивают, что станет с куками и авторизацией, если поставить прокси.

Как отвечать

Суть решения: браузер вообще не должен делать кросс-доменный запрос. Фронтенд ходит на свой origin, а дальше запрос пересылает сервер, для которого CORS не существует.

• локальная разработка: прокси дев-сервера, server.proxy в Vite или devServer.proxy в webpack. Фронтенд обращается к /api, дев-сервер пересылает на бэкенд;
• продакшн: reverse proxy на том же домене, например location /api/ { proxy_pass ... } в nginx. Фронтенд и API оказываются на одном origin, CORS-заголовки не нужны вовсе;
• BFF: свой тонкий бэкенд (Express с http-proxy-middleware, route handlers или rewrites в Next.js), который заодно прячет токены, склеивает ответы и кэширует;
• договориться: настройка CORS это несколько строк в конфиге бэкенда. Придите к команде с конкретикой: какой origin, какие методы и заголовки нужны.

Покажите, что понимаете механику. Запросы с Content-Type: application/json или заголовком Authorization идут с предварительным OPTIONS. При credentials: 'include' сервер обязан вернуть конкретный origin, а не *, плюс Access-Control-Allow-Credentials: true. С прокси на своём домене куки становятся first-party, и эта проблема исчезает.

Где спотыкаются

Предлагают mode: 'no-cors'. Запрос уйдёт, но ответ будет непрозрачным: ни тело, ни статус скрипт не прочитает.

Советуют JSONP или публичные прокси вроде CORS Anywhere. JSONP работает только для GET и исполняет чужой скрипт на вашей странице, а публичный прокси видит все ваши данные и токены.

Пишут прокси, который пересылает запрос на любой URL из параметра. Это открытый прокси и готовая SSRF: адрес назначения должен быть зашит в конфиг.