Сеть/HTTP
CORS Checker / Explainer
Пошагово объяснить, разрешит ли браузер кросс-доменный запрос — simple/preflight-классификация, проверка Access-Control-* заголовков ответа, итог.
По одному на строку, "Имя" или "Имя: значение" — значение на классификацию не влияет.
Возьмите из вкладки Network в DevTools (заголовки самого ответа или preflight OPTIONS) или curl -I.
CORS (Cross-Origin Resource Sharing) — механизм браузера, решающий, разрешить ли JavaScript с одного сайта читать ответ с сервера на другом домене. Инструмент объясняет пошагово, пройдёт ли конкретный запрос, и какие заголовки Access-Control-* для этого нужны.
Как пользоваться
- Укажите метод, origin запроса и заголовки ответа сервера (Access-Control-Allow-Origin и т.д.) — инструмент определит, пропустит ли браузер запрос.
- Классификация «simple» или «preflight» показывает, отправит ли браузер сначала служебный OPTIONS-запрос перед основным.
- Итог указывает точную причину отказа, если запрос не пройдёт, — это экономит время по сравнению с чтением ошибки в консоли браузера.
Типичные сценарии
- Диагностика классической ошибки «has been blocked by CORS policy» без догадок — пошаговое объяснение, чего именно не хватает.
- Проверка конфигурации CORS на бэкенде перед тем, как фронтенд и API окажутся на разных доменах в продакшене.
- Понимание, почему запрос с credentials: include отклоняется, хотя Access-Control-Allow-Origin выглядит правильно.
Что стоит помнить
CORS — это защита браузера пользователя, а не сервера: ограничения действуют только для запросов из кода страницы в браузере, а не для запросов из curl, Postman или сервера к серверу.
Access-Control-Allow-Origin: * несовместим с credentials: include — для запросов с cookie или авторизацией сервер должен вернуть конкретный origin, а не звёздочку.
Статья об этом инструменте: CORS: почему браузер блокирует "обычные" запросы к другому домену
Часто задаваемые вопросы
Почему запрос завершается ошибкой CORS, хотя сервер ответил успешно?
CORS применяется браузером, а не сервером — если в ответе отсутствует заголовок Access-Control-Allow-Origin, соответствующий источнику запроса, браузер блокирует чтение ответа через JavaScript, хотя сам запрос завершился успешно.
В чём разница между простым запросом и запросом с предварительной проверкой (preflight)?
Простые запросы (базовые GET/POST со стандартными заголовками) проходят напрямую, а запросы с пользовательскими заголовками, другими методами или определёнными типами контента сначала вызывают предварительный запрос OPTIONS для проверки разрешения перед отправкой настоящего запроса.
Отправляет ли проверка заголовков CORS здесь мои данные на сервер?
Инструмент проверяет заголовки, которые вы предоставляете, или получает их напрямую из вашего браузера — ни один промежуточный сервер не хранит данные вашего запроса.
Защищает ли CORS API от вредоносных запросов?
Нет. CORS ограничивает лишь то, что браузер разрешит прочитать JavaScript-коду на странице — злоумышленник может отправить тот же запрос напрямую через curl или скрипт, минуя браузер и любые CORS-ограничения полностью.
Почему Access-Control-Allow-Origin: * не работает вместе с credentials: include?
Спецификация запрещает это сочетание намеренно — разрешить любому сайту читать ответы вместе с cookie или авторизацией пользователя было бы серьёзной дырой в безопасности, поэтому в таком случае сервер должен вернуть конкретный Origin, а не "*".