Как сервер запрещает запросы с других доменов и как браузер понимает запрет?

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

Понимаете ли вы, что запрещает не сервер, а браузер, и что сервер лишь сообщает, кому можно читать его ответы. Следом обычно спрашивают, что такое preflight и почему запрос из Postman проходит, а из браузера нет.

Как отвечать

В основе лежит Same-Origin Policy: скрипт со страницы одного источника (схема, домен и порт) не может читать ответы другого. CORS это способ для сервера ослабить правило заголовками:

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

Как браузер понимает запрет: разрешающего заголовка нет или он не совпадает с Origin. Тогда ответ скрипту не отдаётся, fetch отклоняется с TypeError, статус и тело недоступны, подробности видны только в консоли. Если сервер подставляет источник динамически, ему нужен Vary: Origin, иначе кеш перепутает ответы.

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

Думают, что CORS защищает сервер. Простой запрос доходит и выполняется, браузер лишь прячет ответ. От CSRF защищают SameSite и токены, а не CORS.

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

Считают, что сервер должен вернуть 403. Браузеру важны заголовки, а не код: ответ 200 без Access-Control-Allow-Origin заблокирован точно так же.