Содержание статьи

Ошибки CORS (Cross-Origin Resource Sharing) возникают, когда браузер блокирует запрос к ресурсу с другого домена. Это защита, встроенная в современные браузеры, чтобы предотвратить передачу данных между сайтами без разрешения. На практике она часто мешает работе API, особенно при локальной разработке или подключении сторонних сервисов.
Если при запросе вы видите сообщение «No ‘Access-Control-Allow-Origin’ header is present», значит сервер не разрешает доступ вашему домену. Чтобы устранить проблему, нужно проверить настройки заголовков ответа и убедиться, что сервер корректно обрабатывает CORS-запросы.
Настройка CORS включает добавление заголовков Access-Control-Allow-Origin, Access-Control-Allow-Methods и Access-Control-Allow-Headers. Важно задавать их только для нужных источников, чтобы не открывать доступ к серверу всем подряд. Ошибки часто связаны с отсутствием этих заголовков или неправильным форматом ответа на preflight-запрос (OPTIONS).
Для корректной работы стоит проверить логи сервера, включить отладку сети в браузере и протестировать запросы с помощью инструментов вроде curl или вкладки Network в DevTools. Это поможет точно определить, на каком этапе запрос блокируется и какие заголовки отсутствуют.
Почему возникают ошибки CORS и как их распознать
Браузер проверяет, разрешен ли запрос, анализируя ответ сервера на предварительный запрос OPTIONS. Если ответ не содержит заголовок Access-Control-Allow-Origin или содержит его с неверным значением, запрос отклоняется.
- Отсутствует заголовок: сервер не указывает разрешённый источник, и браузер блокирует ответ.
- Неверный домен: сервер разрешает доступ другому домену, не совпадающему с источником запроса.
- Ошибка preflight-запроса: сервер неправильно отвечает на запрос метода OPTIONS.
- Несоответствие методов: сервер не включает нужный HTTP-метод в заголовок Access-Control-Allow-Methods.
- Ограниченные заголовки: клиент отправляет пользовательские заголовки, а сервер не перечисляет их в Access-Control-Allow-Headers.
Распознать проблему можно по сообщению консоли браузера. Примеры типичных ошибок:
- “No ‘Access-Control-Allow-Origin’ header is present on the requested resource” – сервер не вернул нужный заголовок.
- “The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ‘*’” – сервер разрешает доступ всем, но при наличии cookie это запрещено.
- “Response to preflight request doesn’t pass access control check” – ошибка при проверке предварительного запроса.
Для диагностики используйте вкладку Network в DevTools, фильтр по методу OPTIONS и раздел Headers. Это покажет, какие заголовки сервер вернул и что именно вызывает блокировку.
Как проверить заголовки CORS в ответах сервера

Проверка заголовков CORS позволяет определить, разрешает ли сервер запросы с вашего домена. Основное внимание стоит уделить заголовкам Access-Control-Allow-Origin, Access-Control-Allow-Methods и Access-Control-Allow-Headers.
Проще всего проверить их через вкладку Network в DevTools браузера. Найдите нужный запрос, откройте вкладку Headers и просмотрите раздел Response Headers. Если заголовок Access-Control-Allow-Origin отсутствует или указан неверно, браузер заблокирует ответ.
Для проверки вне браузера можно использовать консольные инструменты:
- curl -I https://домен/путь – покажет только заголовки ответа;
- curl -X OPTIONS -i https://домен/путь – отправит preflight-запрос и отобразит полный ответ сервера;
- fetch в консоли браузера – удобен для ручных запросов и анализа ошибок прямо в DevTools.
Если сервер настроен правильно, в ответе должны присутствовать:
- Access-Control-Allow-Origin: адрес вашего сайта или “*” для открытого доступа;
- Access-Control-Allow-Methods: перечень разрешённых HTTP-методов, например GET, POST, PUT;
- Access-Control-Allow-Headers: список пользовательских заголовков, которые клиент может передавать;
- Access-Control-Allow-Credentials: значение true, если разрешена передача cookie.
При отсутствии нужных заголовков необходимо изменить конфигурацию сервера или middleware, чтобы они добавлялись автоматически для всех запросов с допустимых источников.
Настройка заголовков Access-Control-Allow-Origin на сервере

Заголовок Access-Control-Allow-Origin сообщает браузеру, каким источникам разрешено обращаться к серверу. Без него запросы с других доменов блокируются системой безопасности CORS.
Если ресурс должен быть доступен только для одного сайта, укажите конкретный адрес домена. Пример: Access-Control-Allow-Origin: https://example.com. Символ “*” разрешает доступ всем, но не работает при передаче cookie или авторизационных заголовков.
Для Node.js можно добавить настройку напрямую в код:
res.setHeader('Access-Control-Allow-Origin', 'https://example.com');
res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
В Apache настройка выполняется через файл .htaccess или конфигурацию виртуального хоста:
Header set Access-Control-Allow-Origin "https://example.com"
Header set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header set Access-Control-Allow-Headers "Content-Type, Authorization"
В Nginx добавьте директивы в блок server или location:
add_header 'Access-Control-Allow-Origin' 'https://example.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
Если сервер обслуживает несколько доменов, используйте логику проверки переменной Origin и возвращайте заголовок только при совпадении с разрешёнными адресами. Это позволяет избежать ошибок доступа и сохранить безопасность.
После внесения изменений выполните запрос с помощью curl -I или панели Network в браузере, чтобы убедиться, что заголовки передаются в ответе сервера.
Как разрешить CORS-запросы только с нужных доменов

Чтобы ограничить доступ к серверу, нужно задать список доменов, которым разрешены CORS-запросы. Это исключает возможность обращения посторонних сайтов и снижает риск утечек данных.
На практике список допустимых источников можно хранить в конфигурации сервера или файле окружения. При каждом запросе сервер сравнивает значение заголовка Origin с разрешёнными доменами и добавляет заголовок Access-Control-Allow-Origin только при совпадении.
Пример логики на Node.js:
const allowedOrigins = ['https://example.com', 'https://admin.example.com'];
const origin = req.headers.origin;
if (allowedOrigins.includes(origin)) {
res.setHeader('Access-Control-Allow-Origin', origin);
}
Пример конфигурации для Nginx:
if ($http_origin = "https://example.com") {
add_header 'Access-Control-Allow-Origin' "$http_origin";
}
Таблица рекомендуемых настроек для разных сценариев:
| Сценарий | Настройка | Примечание |
|---|---|---|
| Один доверенный домен | Access-Control-Allow-Origin: https://example.com | Безопасный вариант, подходит для большинства сайтов |
| Несколько поддоменов | Проверка значения Origin на стороне сервера | Гибкая настройка без открытия доступа всем |
| Разработка локально | Access-Control-Allow-Origin: http://localhost:3000 | Разрешает запросы только с локальной среды |
После изменения настроек проверяйте ответы сервера с помощью curl -I или вкладки Network, чтобы убедиться, что заголовок добавляется только при запросах с разрешённых доменов.
Настройка CORS в Apache, Nginx и Node.js
Для корректной работы CORS на сервере необходимо добавить соответствующие заголовки, разрешающие доступ нужным источникам.
В Apache настройка выполняется через файл .htaccess или конфигурацию виртуального хоста. Минимальные заголовки для разрешения запросов с одного домена:
Header set Access-Control-Allow-Origin "https://example.com"
Header set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header set Access-Control-Allow-Headers "Content-Type, Authorization"
Для Nginx директивы добавляются в блок server или location. Пример:
add_header 'Access-Control-Allow-Origin' 'https://example.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
В Node.js с использованием Express настройка выполняется через middleware:
app.use((req, res, next) => {
const allowedOrigins = ['https://example.com', 'https://admin.example.com'];
const origin = req.headers.origin;
if (allowedOrigins.includes(origin)) {
res.setHeader('Access-Control-Allow-Origin', origin);
}
res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
next();
});
После внесения изменений нужно перезапустить сервер и проверить заголовки через curl -I или вкладку Network в DevTools, чтобы убедиться, что они применяются правильно.
Как временно обойти CORS при разработке

При локальной разработке CORS может блокировать запросы к API на других доменах. Временные обходы позволяют тестировать функционал без изменения серверной конфигурации.
- Использование прокси: настраивают локальный сервер, который перенаправляет запросы к целевому API. Пример для Node.js: http-proxy-middleware в Express.
- Расширения браузера: доступны плагины, которые временно отключают проверку CORS, например для Chrome или Firefox. Использовать только в тестовой среде.
- Запуск браузера с отключённой проверкой: Chrome можно запустить с параметром —disable-web-security —user-data-dir. Не использовать для постоянной работы.
- JSONP: работает только для GET-запросов, позволяет обходить CORS на старых API без настройки заголовков.
- Локальная копия API: скачивание данных и работа с ними на локальном сервере без запросов к внешним ресурсам.
При тестировании важно помнить, что эти методы не меняют настройки сервера и подходят только для разработки. Для боевой среды необходимо настроить заголовки CORS корректно на сервере.
Как проверить, что настройки CORS применились правильно

После внесения изменений в конфигурацию сервера важно убедиться, что заголовки CORS передаются корректно и браузер разрешает запросы с нужных источников.
Проверку можно выполнить следующими способами:
- Вкладка Network в DevTools: откройте браузер, отправьте запрос и проверьте раздел Response Headers. Заголовки Access-Control-Allow-Origin, Access-Control-Allow-Methods и Access-Control-Allow-Headers должны присутствовать и соответствовать ожиданиям.
- Preflight-запрос: отправка OPTIONS-запроса через DevTools или curl позволяет убедиться, что сервер правильно отвечает на проверку методов и заголовков.
- Использование curl: команда curl -I https://домен/путь покажет заголовки ответа, а curl -X OPTIONS -i https://домен/путь – проверку preflight.
- JavaScript fetch: выполните fetch-запрос с нужного домена и проверьте, не возникает ли ошибка CORS в консоли браузера.
Если заголовки отсутствуют или значения неверные, нужно проверить конфигурацию сервера, убедиться, что она активна и применена после перезапуска. После успешной проверки все запросы с разрешённых доменов должны проходить без ошибок.
Вопрос-ответ:
Почему браузер блокирует мои запросы к API с другого домена?
Браузер проверяет, разрешает ли сервер доступ к своим ресурсам с вашего домена. Если сервер не возвращает заголовок Access-Control-Allow-Origin или возвращает его с неправильным значением, браузер блокирует запрос. Это стандартная защита CORS, предотвращающая несанкционированный доступ к данным.
Как проверить, какие заголовки CORS возвращает сервер?
Для проверки используйте вкладку Network в DevTools браузера. Выберите нужный запрос и откройте раздел Response Headers. Заголовки Access-Control-Allow-Origin, Access-Control-Allow-Methods и Access-Control-Allow-Headers должны присутствовать. В командной строке можно использовать curl -I https://домен/путь для просмотра заголовков ответа.
Как настроить сервер, чтобы разрешить запросы только с определённых доменов?
На сервере хранится список разрешённых доменов. При каждом запросе проверяется заголовок Origin и, если домен совпадает с допустимым, сервер возвращает Access-Control-Allow-Origin с этим значением. В Node.js это реализуется через middleware, в Nginx и Apache — через директивы add_header или Header set.
Можно ли временно обойти блокировку CORS при разработке?
Да, для локальной разработки можно использовать прокси, которые перенаправляют запросы, запускать браузер с отключённой проверкой CORS или использовать расширения для браузера. Такие методы подходят только для тестирования и не заменяют правильную настройку сервера.
Как убедиться, что изменения в настройках CORS применились правильно?
Проверить можно с помощью preflight-запросов OPTIONS через DevTools или команду curl -X OPTIONS -i https://домен/путь. Также отправьте fetch-запрос с нужного домена и следите за консолью браузера. Если заголовки возвращаются корректно и ошибки CORS не появляются, настройки применены верно.
Почему мой браузер блокирует запросы к серверу с другого домена?
Браузер блокирует такие запросы из-за политики CORS. Когда скрипт с одного домена обращается к ресурсу на другом домене, браузер отправляет проверочный запрос OPTIONS или проверяет заголовки ответа. Если сервер не возвращает заголовок Access-Control-Allow-Origin с вашим доменом, браузер не разрешает доступ к данным. Для решения проблемы нужно настроить сервер, чтобы он добавлял этот заголовок для доверенных источников, а также указывать разрешённые методы через Access-Control-Allow-Methods и допустимые заголовки через Access-Control-Allow-Headers. Проверить работу можно через вкладку Network в DevTools или с помощью команды curl -I.
