Сеть/HTTP
CORS Checker / Explainer
Пошагово объяснить, разрешит ли браузер кросс-доменный запрос — simple/preflight-классификация, проверка Access-Control-* заголовков ответа, итог.
По одному на строку, "Имя" или "Имя: значение" — значение на классификацию не влияет.
Возьмите из вкладки Network в DevTools (заголовки самого ответа или preflight OPTIONS) или curl -I.
CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
Статья об этом инструменте: 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, а не "*".