Как бороться с CORS при ошибках запросов к API?

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

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

Как отвечать

Начните с сути. Браузер соблюдает Same-Origin Policy: скрипт со страницы https://app.example.com не прочитает ответ https://api.example.com, пока сервер явно не разрешит это заголовками. Сам запрос при этом часто доходит до сервера, браузер блокирует только чтение ответа.

Виды запросов:

• простые: GET, HEAD, POST с безопасными заголовками и Content-Type вроде text/plain или multipart/form-data. Уходят сразу, в ответе нужен Access-Control-Allow-Origin;
• с preflight: PUT, DELETE, Content-Type: application/json, заголовок Authorization. Сначала браузер шлёт OPTIONS, сервер отвечает Access-Control-Allow-Methods и Access-Control-Allow-Headers;
• с учётными данными: credentials: 'include' требует Access-Control-Allow-Credentials: true и конкретный origin, звёздочка здесь не работает.

Решения по порядку. Настроить CORS на API (middleware cors в Express, CorsConfiguration в Spring), а при динамическом origin добавить Vary: Origin. В разработке проксировать через dev-сервер: server.proxy в Vite, rewrites в Next.js. Если API чужой, ходить через свой бэкенд (BFF).

Отлаживают во вкладке Network: сервер часто падает с 500 без CORS-заголовков, и в консоли это выглядит как ошибка CORS.

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

Ставят mode: 'no-cors'. Ошибка пропадает, но ответ становится opaque, прочитать из него ничего нельзя.

Отражают любой пришедший Origin вместе с Allow-Credentials: true. Так API с куками пользователя открывается любому сайту.

Считают CORS защитой API. curl и Postman его не соблюдают, авторизацию сервер обязан проверять сам. А * для публичного API без кук вполне нормальный вариант.