Что такое политика CORS и как она работает
Что проверяют
Понимаете ли вы, откуда берётся ошибка, которую фронтенд приносит бэкендеру со словами, что сервер не настроен. За вопросом стоит знание правила одного источника в браузере и понимание, что CORS это управляемое ослабление этого правила, а не дополнительная защита.
Как отвечать
Браузер по умолчанию не даёт странице с одного источника прочитать ответ с другого; источник это схема, хост и порт вместе. CORS это способ серверу заголовками ответа разрешить такое чтение конкретным источникам.
Простые запросы уходят сразу, и без разрешения браузер просто прячет ответ от кода страницы. Всё остальное (нестандартный метод, свои заголовки, иной тип содержимого) вызывает предварительный запрос методом OPTIONS с заголовками Access-Control-Request-Method и Access-Control-Request-Headers.
Заголовки ответа, которые надо назвать: Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials, Expose-Headers для доступа к своим заголовкам ответа из кода, Max-Age для кэша предварительного запроса.
В Go это промежуточный обработчик: сверяет Origin со списком разрешённых, выставляет заголовки и на OPTIONS отвечает сам, не пуская запрос дальше в маршрутизатор.
Где спотыкаются
Называют CORS защитой от подделки межсайтового запроса. Это разные механизмы: запрос уходит на сервер в любом случае, изменения применяются, браузер лишь скрывает ответ. От подделки защищают токен и атрибут SameSite у куки.
Ставят звёздочку в Allow-Origin и одновременно включают отправку куки. Браузер такое сочетание отвергает: с учётными данными нужен конкретный источник в ответе, признак Allow-Credentials и обязательный Vary по Origin, иначе кэш отдаст одному источнику разрешение, выписанное другому.
Проверяют сервер через консольный клиент, видят корректный ответ и делают вывод, что всё работает. Правило источника применяет только браузер. Обратная сторона той же ошибки: разрешение всем источникам не заменяет авторизацию, проверять права обязан сам сервер.