Как отключить cors в chrome

Несколько советов по работе с CORS для начинающих разработчиков

В этой статье мы с вами разберемся, что такое CORS, CORS-ошибки и из-за чего мы можем с ними сталкиваться. Я также продемонстрирую возможные решения и объясню, что такое предварительные (preflight) запросы, CORS-заголовки и в чем заключается их важность при обмене данными между сторонами. Эта статья рассчитана на тех, у кого уже есть базовые познания в области веб-разработки и некоторый опыт с протоколом HTTP. Я старался писать статью так, чтобы она была понятна и новичкам, будучи наполненной знаниями, но при этом стараясь избегать слишком большого количества технических нюансов, не связанных с темой CORS. Если вы заметите какие-либо ошибки или у вас будут предложения, не стесняйтесь писать мне. В некоторых местах я нарочно делал упрощения, говоря “служба”, подразумевая “сервер”, и наоборот.

Что такое CORS?

Cross-Origin Resource Sharing (CORS или “совместное использование ресурсов различными источниками”) — это контролируемый и применяемый в принудительном порядке клиентом (браузером) механизм обеспечения безопасности на основе HTTP. Он позволяет службе (API) указывать любой источник (origin), помимо себя, из которого клиент может запрашивать ресурсы. Он был разработан в соответствии с same-origin policy (SOP или “политика одинакового источника”), которая ограничивает взаимодействие сайта (HTML-документа или JS-скрипта), загруженного из одного источника, с ресурсом из другого источника. CORS используется для явного разрешения определенных cross-origin запросов и отклонения всех остальных.

В основном CORS реализуют веб-браузеры, но как вариант его также можно использовать в API-клиентах. Он присутствует во всех популярных браузерах, таких как Google Chrome, Firefox, Opera и Safari. Этот стандарт был принят в качестве рекомендации W3C в январе 2014 года. Исходя из этого, можно смело предполагать, что он реализован во всех доступных в настоящее время браузерах, которые не были перечислены выше.

Как это работает?

Все начинается на стороне клиента, еще до отправки основного запроса. Клиент отправляет в службу с ресурсами предварительный (preflight) CORS-запрос с определенными параметрами в заголовках HTTP (CORS-заголовках, если быть точнее). Служба отвечает, используя те же заголовки с другими или такими же значениями. На основе ответа на предварительный CORS-запрос клиент решает, может ли он отправить основной запрос к службе. Браузер (клиент) выдаст ошибку, если ответ не соответствует требованиям предварительной проверки CORS.

Предварительные CORS-запросы отправляются независимо от используемых для отправки запросов из браузера библиотек или фреймворков. Поэтому вам не нужно соответствовать требованиям CORS, когда вы работе с API из вашего серверного приложения.

CORS не будет препятствовать пользователям запрашивать или загружать ресурсы. Вы прежнему можете успешно запросить ресурс с помощью таких приложений, как curl, Insomnia или Postman. CORS будет препятствовать доступу браузера к ресурсу только в том случае, если политика CORS не разрешает этого.

Что такое предварительная проверка CORS?

Когда браузер отправляет запрос на сервер, он сначала отправляет Options HTTP-запрос. Это и есть предварительным CORS-запрос. Затем сервер отвечает списком разрешенных методов и заголовков. Если браузеру разрешено сделать фактический запрос, то тогда он незамедлительно отправит его. Если нет, он покажет пользователю ошибку и не выполнит основной запрос.

CORS-заголовки

CORS-заголовки — это обычные заголовки HTTP, которые используются для контроля политики CORS. Они используются, когда браузер отправляет предварительный CORS-запрос на сервер, на который сервер отвечает следующими заголовками:

• Access-Control-Allow-Origin указывает, какой источник может получать ресурсы. Вы можете указать один или несколько источников через запятую, например: https://foo.io,http://bar.io .
• Access-Control-Allow-Methods указывает, какие HTTP-методы разрешены. Вы можете указать один или несколько HTTP-методов через запятую, например: GET,PUT,POST .
• Access-Control-Allow-Headers указывает, какие заголовки запросов разрешены. Вы можете указать один или несколько заголовков через запятую, например: Authorization,X-My-Token .
• Access-Control-Allow-Credentials указывает, разрешена ли отправка файлов cookie. По умолчанию: false .
• Access-Control-Max-Age указывает в секундах, как долго должен кэшироваться результат запроса. По умолчанию: 0.

Если вы решите использовать Access-Control-Allow-Credentials=true , то вам нужно знать, что вы не сможете использовать символы * в заголовках Access-Control-Allow-* . Необходимо будет явно перечислить все разрешенные источники, методы и заголовки.

Полный список CORS-заголовков вы можете найти здесь.

Почему запрос может быть заблокирован политикой CORS?

Если вы веб-разработчик, вы, вероятно, уже слышали или даже сталкивались с CORS-ошибками, имея за плечами часы, потраченные на поиски их причин и решений. Наиболее распространенная проблема заключается в том, что браузер блокирует запрос из-за политики CORS. Браузер выдаст ошибку и отобразит в консоли следующее сообщение:

Access to XMLHttpRequest at 'http://localhost:8080/' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Приведенная выше CORS-ошибка уведомляет пользователя о том, что браузер не может получить доступ к ресурсу ( https://localhost:8080 ) из источника ( https://localhost:3000 ), поскольку сервер его не одобрил. Это произошло из-за того, что сервер не ответил заголовком Access-Control-Allow-Origin с этим источником или символом * в ответе на предварительный CORS-запрос.

Запрос может быть заблокирован политикой CORS не только из-за невалидного источника, но и из-за неразрешенных заголовка HTTP, HTTP-метода или заголовка Cookie.

Как исправить CORS-ошибку?

Фундаментальная идея “исправления CORS” заключается в том, чтобы отвечать на OPTIONS запросы, отправленные от клиента, корректными заголовками. Есть много способов начать отвечать корректными CORS. Вы можете использовать прокси-сервер или какое-нибудь middleware на своем сервере.

Помните, что заголовки Access-Control-* кэшируются в браузере в соответствии со значением, установленным в заголовке Access-Control-Max-Age . Поэтому перед тестированием изменений вам обязательно нужно чистить кэш. Вы также можете отключить кэширование в своем браузере.

1. Настройка вашего сервера

По умолчанию, если вы являетесь владельцем сервера, вам необходимо настроить на своем сервере CORS-ответы, и это единственный способ правильно решить проблему. Вы можете добиться этого несколькими способами из нескольких слоев вашего приложения. Самый распространенный способ — использовать обратный прокси-сервер (reverse-proxy), API-шлюз или любой другой сервис маршрутизации, который позволяет добавлять заголовки к ответам. Для этого можно использовать множество сервисов, и вот некоторые из них: HAProxy, Linkerd, Istio, Kong, nginx, Apache, Traefik. Если ваша инфраструктура содержит только приложение без каких-либо дополнительных слоев, то вы можете добавить поддержку CORS в код самого приложения.

Вот несколько популярных примеров активации CORS:

• Apache: отредактируйте файл .htaccess
• Nginx: отредактируйте файл конфигурации,
• Traefik: используйте middleware,
• Spring Boot: используйте аннотацию @EnableCORS,
• ExpressJS: используйте app.use(cors()),
• NextJS: используйте реквест-хелперы.

Здесь вы можете найти больше примеров активации CORS для разных фреймворков и языков: enable-cors.org.

Если вы не можете активировать CORS в службе, но все же хотите сделать возможными запросы к ней, то вам нужно использовать одно из следующих решений, описанных ниже.

2. Установка расширения для браузера

Использование расширения для браузера может быть быстрым и простым способом решения проблем с CORS в вашей среде разработки. Самым большим преимуществом использования расширения для браузера является то, что вам не нужно менять свой код или конфигурацию. С другой стороны, вам необходимо установить расширение в каждый браузер, который вы используете для тестирования своего веб-приложения.

Расширения для браузера изменяют входящий предварительный запрос, добавляя необходимые заголовки, чтобы обмануть браузер. Это очень удобное решение для локальной работы с производственным API, которое принимает запросы только из рабочего домена.

Вы можете найти расширения в Google Web Store или в библиотеке дополнений Mozilla. В некоторых случаях дефолтной конфигурации расширения может быть недостаточно; убедитесь, что установленное расширение корректно настроено. Вам также следует быть в курсе, что если держать подобное расширение включенным постоянно, то это может вызвать проблемы с некоторыми сайтами. Их рекомендуется использовать только в целях разработки.

3. Отключение CORS-проверок в браузере

Вы можете полностью отключить CORS-проверки в своем браузере. Чтобы отключить CORS-проверки в Google Chrome, нужно закрыть браузер и запустить его с флагами —disable-web-security и —user-data-dir . После запуска Google Chrome не будет отправлять предварительные CORS-запросы и не будет проверять CORS-заголовки.

# Windows chrome.exe --user-data-dir="C://chrome-dev-disabled-security" --disable-web-security --disable-site-isolation-trials # macOS open /Applications/Google\ Chrome.app --args --user-data-dir="/var/tmp/chrome-dev-disabled-security" --disable-web-security --disable-site-isolation-trials # Linux google-chrome --user-data-dir="~/chrome-dev-disabled-security" --disable-web-security --disable-site-isolation-trials

Все команды, приведенные выше, запускают Google Chrome в изолированной безопасной среде. Они не затронут ваш основной профиль Chrome.

4. Настройка прокси-сервера

Если вы ищете решение, которое не требует от вас изменения настроек браузера, вам следует обратить внимание на прокси-сервера. Эта опция поможет вам избавиться от CORS-ошибок, ничего не меняя в самом браузере. Идея подхода заключается в том, чтобы отправлять все запросы на ваш сервер, который затем перенаправит запрос реальной службе, которую вы хотите использовать. Вы можете создать прокси-сервер самостоятельно с помощью языка и платформы по вашему предпочтению. Вам потребуется настроить CORS и реализовать функционал передачи полученных запросов в другую службу.

Прокси-сервер — хорошее решение, если у вас нет доступа к службе, которую вы собираетесь использовать. Существует множество готовых к использованию решений с открытым исходным кодом для создания прокси-серверов, но вам обязательно нужно следить за тем, чтобы они не пытались перехватить ваши запросы с заголовками авторизации и передать их какой-либо сторонней службе. Такие нарушения безопасности могут привести к катастрофическим последствиям как для вас, так и для потенциальных пользователей службы.

Ниже приведен список CORS сервисов с открытым исходным кодом, которые вы можете найти на просторах интернета:

• https://github.com/Freeboard/thingproxy
• https://github.com/bulletmark/corsproxy
• https://github.com/Rob—W/cors-anywhere

Перед использованием любого из этих сервисов обязательно проверьте код самой последний версии версии.

Как протестировать CORS?

Использование браузера для проверки конфигурации CORS может оказаться на удивление утомительной задачей. В качестве альтернативы вы можете использовать такие инструменты, как CORS Tester, test-cors.org или, если вас не страшит командная строка, вы можете использовать curl для проверки конфигурации CORS.

curl -v -X OPTIONS https://simplelocalize.io/api/v1/translations

Остерегайтесь ложных CORS-ошибок

В некоторых случаях, когда сервис находится за дополнительным слоем защиты ограничителя частоты запросов, балансировщика нагрузки или сервера авторизации, вы можете получить ложную CORS-ошибку. Заблокированные или отклоненные сервером запросы должны отвечать статус кодами ошибки. Например:

• 401 unauthorized,
• 403 forbidden,
• 429 too many requests,
• 500 internal server error,
• любые, кроме 2XX или 3XX.

Вы можете видеть, что запрос заблокирован из-за неудачного предварительного запроса, но на самом деле служба просто отклоняет его. Вы всегда должны проверять статус код и текст ответа, чтобы избежать излишней отладки. Браузер должным образом уведомляет вас о сбое в предварительном CORS-запросе, но причина сбоя может быть не связана с конфигурацией CORS.

Заключение

В этой статье я постарался объяснить, что такое CORS и каковы наиболее распространенные проблемы с ним. Я предложил четыре способа избавиться от проблемы с CORS и объяснил преимущества и недостатки каждого из них. Я также объяснил, как правильно настроить CORS-ответы и как их протестировать. Более того, я показал самые распространенные проблемы, с которыми вы можете столкнуться при распознавании ложных CORS-ошибок. Я постарался изложить все максимально простым языком и избежать мудреных технических подробностей. Cпасибо за внимание!

Полезные ссылки

• https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors
• https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
• https://enable-cors.org/
• https://stackoverflow.com/a/42024918/1133169

Материал подготовлен в преддверии старта онлайн-курса «JavaScript Developer. Professional». Недавно прошел открытый урок на тему «CSS-in-JS. Удобный способ управлять стилями», на котором рассмотрели Styled components, Linaria, Astroturf и другие инструменты упрощения работы со стилями. Посмотреть запись можно по ссылке.

Как избежать CORS в одностраничных приложениях

За последнее десятилетие применение технологии одностраничных приложений стало обычным явлением при создании веб-приложений. Сегодня во фронтенд-разработке господствуют такие фреймворки, как Angular и Vue, и такие библиотеки, как React, обеспечивающие базовую платформу для этих приложений. Преимущества заключаются в том, что они обслуживают API фронтенда и бэкенда из одного домена. Но есть случаи, когда фронтенд (например, web.myapp.com) и бэкенд (например, api.myapp.com) обслуживаются из отдельных поддоменов. Также иногда мы разрешаем доступ из разных источников через API бэкенда только для среды разработки.

Обмен ресурсами между разными источниками (Cross-origin resource sharing — CORS) — это механизм, реализуемый в веб-браузерах для разрешения или отклонения запросов, поступающих из другого домена в веб-приложение. С помощью CORS веб-браузеры и веб-серверы согласовывают стандартный протокол, определяющий, стоит ли разрешить доступ к определенным ресурсам. Помните, что принудительное применение CORS со стороны бэкенда не означает, что боты или любой другой механизм не могут получить доступ к ресурсам сервера.

Нужно ли использовать CORS?

Нужно ли разрешать CORS для веб-приложений? Стоит сказать, что в большинстве случаев вам не нужно беспокоиться о CORS, поскольку веб-приложение обслуживается из одного домена. Однако в приложении могут быть специальные функции, такие как возможность встраивания страницы (например, Form, Video) за пределами основного домена веб-приложения. В таком случае можно рассмотреть возможность включения CORS в бэкенде только для этой конкретной функции.

Недостатки CORS

Наиболее очевидным недостатком CORS, помимо безопасности, является влияние на производительность в веб-приложениях. Когда фронтенд отправляет HTTP-запрос на другой домен или поддомен, браузер отправляет дополнительный HTTP-запрос (предзапрос), чтобы узнать, принимает ли сервер сообщения из домена отправителя.

Таким образом, для каждого HTTP-запроса, запускаемого фронтендом, браузер должен отправить два HTTP-запроса, что увеличивает общее время ответа. В большинстве случаев добавленная задержка заметна в веб-приложениях и отрицательно влияет на опыт для пользователей.

CORS в одностраничных приложениях

Когда дело доходит до одностраничных приложений, использование CORS становится гораздо более заметным. Веб-браузеры не будут рассматривать предзапрос, если веб-приложение использует только HTTP-заголовки ( Accept , Accept-Language , DPR , Downlink , Save-Data , Viewport-Width , Width , Content-Language , Content-Type , за исключением значений application/x-www-form-urlencoded , multipart/form-data , text/plan ) и HTTP-методы ( GET , HEAD , POST ) для вызовов API бэкенда. Скорее всего, вам понадобятся эти HTTP-заголовки и HTTP-методы в одностраничных приложениях.

В этих приложениях URL API бэкенда определен во фронтенде как переменная для операций сервера. Кроме того, мы даже можем предоставить CORS в API бэкенда, поскольку сервер разработки для API фронтенда и бэкенда, возможно, работает на двух разных портах. Среда разработки также может повлиять на настройки в окружении продакшна, где вы, возможно, развернете API фронтенда и бэкенда на разных поддоменах.

Стоит ли идти в этом направлении? Давайте рассмотрим способы, как избежать использования CORS как для среды разработки, так и для окружения продакшна.

Как избежать CORS в среде разработки

Сегодня большинство серверов разработки для фронтенда используют NodeJS. Большинство из этих Node-серверов поддерживают настройку прокси. Кроме того, Angular, React и Vue поставляются с Webpack, который имеет встроенную поддержку настройки прокси.

Что именно делает эта настройка прокси?

Предположим, что ваше веб-приложение запущено по адресу http://localhost:4200 , а API бэкенда — http://localhost:3000/api/ . Фронтенд должен хранить URL-адрес и порт API бэкенда, чтобы запускать приложение локально. Кроме того, вам также нужно будет включить CORS в API бэкенда, разрешив вызовы API, поступающие из фронтенда. В данном случае API фронтенда и бэкенда одинаковы ( http://localhost ), но порты разные, и браузер считает их разными источниками.

Чтобы избежать всех вышеперечисленных хлопот, можно использовать настройку прокси на серверах фронтенд-разработки. Когда вы используете прокси, вам нужно хранить только относительный путь ( /api ) во фронтенд-приложении. При локальном запуске приложения фронтенд попытается получить доступ к API бэкэнда, используя тот же домен и порт ( http://localhost:4200/api/ ), а браузер не будет беспокоиться о CORS.

На этом этапе прокси делает свое дело. Внутри настройки прокси можно указать перенаправление любых запросов, поступающих для пути /api , на http://localhost:3000 на сервер фронтенд-разработки.

Поскольку сервер разработки является посредником, взаимодействующим с API бэкенда, он может безопасно избежать CORS. В приведенном ниже примере показано, как добавить настройку прокси на сервере разработки Webpack.

module.exports = //. 
devServer: proxy: '/api': 'http://localhost:3000' 
> 
>
>;

В качестве альтернативного подхода вы можете запустить веб-браузер со специальными флагами, чтобы отключить CORS для локального тестирования, если вы не хотите использовать относительные пути во фронтенде для API бэкенда. Например, запустить браузер Chrome без CORS.

Как избежать CORS в окружении продакшна

В окружении продакшна вам необходимо настроить шлюз или прокси перед API фронтенда и бэкенда для обслуживания из одного домена, если они не работают внутри одного веб-сервера. В некоторых случаях балансировщика нагрузки будет достаточно, если он может маршрутизировать в различные конечные точки на основе путей HTTP.

Подобно прокси сервера разработки, шлюз, прокси или балансировщик нагрузки выполняет маршрутизацию на основе предоставленной конфигурации в соответствии с путем HTTP, полученным в запросе. Ниже приведен список из нескольких популярных шлюзов, прокси и балансировщиков нагрузки, которые поддерживают маршрутизацию на основе пути URL:

• NGINX;
• Traefik;
• AWS CloudFront;
• AWS Application Load Balancer;
• Azure Application Gateway.

Кроме того, важно укрепить API бэкенда для CORS, разрешив доступ только из одного источника.

Заключение

Я надеюсь, что вы разобрались в том, как CORS влияет на производительность и в чем преимущества избежания его использования в одностраничных приложениях. Безопасность является основной причиной создания CORS в современных браузерах, поэтому очень важно знать основы его работы с этой точки зрения. Здесь мы рассмотрели лишь способы избежания CORS в одностраничных приложениях.

Поскольку мы затронули тему использования прокси, чтобы избежать CORS, вы, возможно, задаетесь вопросом, насколько сложно настроить прокси, когда API фронтенда и бэкенда работают в отдельных сервисах. Тем не менее выполнить настройку проще, чем вы думаете. Например, при настройке прокси сервера разработки для Angular, React или Vue необходимо добавить несколько строк в конфигурационном файле Webpack, чтобы перенаправить запросы к API бэкенда для избежания CORS. То же самое относится и к окружениям продакшна, поскольку существуют устоявшиеся способы реализации маршрутизации на основе пути URL.

Однако вы должны установить правильное преобразование пути для API бэкенда, чтобы избежать необходимости обновлять настройку прокси при каждом добавлении новой конечной точки. Например, если вы используете базовый путь, такой как \api\ , проще написать простое правило для маршрутизации запросов к API бэкенда для всех запросов, имеющих базовый путь, и fallback к фронтенд-ресурсам для других путей HTTP.

Напоследок хотелось бы еще раз подчеркнуть, что если у вас нет каких-либо требований по использованию CORS, включите доступ только для одного источника для API бэкенда, как в среде разработки, так и в окружении продакшна. По моему опыту, такой подход сэкономит время в будущем и поможет избежать многих ловушек.

• Что такое Deno и заменит ли он NodeJS?
• Веб-сервер с нуля в TypeScript и Node
• Фильтруем баги. Как реализовать тестовое покрытие в TypeScript под Node.js с помощью Jest

CORS: просто и понятно говорим про ошибки кроссдоменных запросов

Меня зовут Радик, я frontend developer компании Creative. И сегодня я хочу поднять тему, которая касается и фронта и бэка, и окружает нас с вами каждый день. Речь пойдёт об ошибках CORS и как их можно обойти.

Уверен, что многим разрабам знакома ситуация, когда ты работаешь над приложением, оно запущено локально, и тебе нужно сделать из него запросы к различным удалённым ресурсам. В этот момент «что-то идёт не так», и ты видишь на своём экране миллион ошибок в консоли браузера. Почему они появляются? Давайте разбираться вместе. В этой статье расскажу о средствах защиты браузера и о том, что он может от вас скрывать в процессе кроссдоменных запросов. Фича: об ошибках будем говорить в картинках 🙂

SOP – Same Origin Policy

Рассмотрим кейс. Мы заходим на какой-то незнакомый сайт, созданный потенциальным злоумышленником. Внешне пока не видим ничего подозрительного, но пока мы находимся на этом сайте, злобный скрипт уже готовит запрос к серверу банка, в котором мы залогинены, и пытается получить наши данные:

Как же браузер пытается нас от этого защитить? Он использует Политику одинакового источника: Same Origin Policy (SOP).

В тех случаях, когда запрос отправляется на ресурс, у которого отличается домен / порт / протокол, – браузер по умолчанию понимает, что он кроссдоменный и применяет политику безопасности:

CORS – Cross Origin Resource Sharing

Что же делать в том случае, когда нам необходимо разрешить для браузера взаимодействие между различными ресурсами?

Браузер должен отправить в запросе заголовок:

**origin: htttps://good-website.com**

Сервер проверит, откуда к нему пришёл запрос, и (если этот домен разрешён) в ответе вернёт заголовок:

**access-control-allow-origin: htttps://good-website.com**

ACAH – Access-Control-Allow-Headers

Браузер может запретить доступ к некоторым заголовкам ответа из кода, ничего не сообщив при этом разработчику.

Так получается, потому что по умолчанию при кроссдоменных запросах браузер разрешает чтение только следующих заголовков ответа:

• Cache-Control
• Content-Language
• Content-Length
• Content-Type
• Expires
• Last-Modified
• Pragma

Поэтому в network вкладке браузера мы видим абсолютно все интересующие нас заголовки, а из кода JS они будут нам недоступны.

Run Chrome browser without CORS

I use this sometimes, for posting a localhost frontend app to a localhost backend API. I created a separate shortcut on my Windows 10 laptop, so that it never is used for normal browsing, only for debugging locally.

Windows

Just do follow steps:

• Right click on desktop, add new shortcut
• Add the target as «[PATH_TO_CHROME]\chrome.exe» —disable-web-security —disable-gpu —user-data-dir=%LOCALAPPDATA%\Google\chromeTemp
• Click OK.

NOTE: On Windows command will be: «C:\Program Files\Google\Chrome\Application\chrome.exe» —disable-web-security —disable-gpu —user-data-dir=%LOCALAPPDATA%\Google\chromeTemp

OSX

open -n -a /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome —args —user-data-dir=»/tmp/chrome_dev_test» —disable-web-security

Linux

If you need access to local files for dev purposes like AJAX or JSON, you can use -–allow-file-access-from-files flag.

Remark

Since Chrome 22+ you will get an error message that says:

You are using an unsupported command-line flag: —disable-web-security . Stability and security will suffer.

However you can just ignore that message while developing.

Links

• Disable same origin policy in Chrome
• Disable-web-security in Chrome 48+