Как избежать 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.

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

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

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

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

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

Заключение

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

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

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

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

Disable-web-security in Chrome 48+

I have a problem with the —disable-web-security flag. It is not working in Chrome 48 and Chrome 49 beta on Windows.

I’ve tried killing all of the instances, reboot and run Chrome with the flag first of all, tried different machines as well. In the beta I can see the warning popup («You are using unsupported flag..»), but CORS is still being enforced. Public version seems to ignore the flag completely.

There seems to be no news or people reports about that, so it might be a local issue. Will be grateful for help or any related info.

13 Answers 13

Update 2020-04-30

As of Chrome 81, it is mandatory to pass both —disable-site-isolation-trials and a non-empty profile path via —user-data-dir in order for —disable-web-security to take effect:

(Speculation) It is likely that Chrome requires a non-empty profile path to mitigate the high security risk of launching the browser with web security disabled on the default profile. See —user-data-dir= vs —user-data-dir=/some/path for more details below.

Thanks to @Snæbjørn for the Chrome 81 tip in the comments.

Update 2020-03-06

As of Chrome 80 (possibly even earlier), the combination of flags —user-data-dir=/tmp/some-path —disable-web-security —disable-site-isolation-trials no longer disables web security.

It is unclear when the Chromium codebase regressed, but downloading an older build of Chromium (following «Not-so-easy steps» on the Chromium download page) is the only workaround I found. I ended up using Version 77.0.3865.0, which properly disables web security with these flags.

Original Post 2019-11-01

In Chrome 67+, it is necessary to pass the —disable-site-isolation-trials flag alongside arguments —user-data-dir= and —disable-web-security to truly disable web security.

On MacOS, the full command becomes:

Regarding —user-data-dir

Per David Amey’s answer, it is still necessary to specify —user-data-dir= for Chrome to respect the —disable-web-security option.

—user-data-dir= vs —user-data-dir=/some/path

Though passing in an empty path via —user-data-dir= works with —disable-web-security , it is not recommended for security purposes as it uses your default Chrome profile, which has active login sessions to email, etc. With Chrome security disabled, your active sessions are thus vulnerable to additional in-browser exploits.

Thus, it is recommended to use an alternative directory for your Chrome profile with —user-data-dir=/tmp/chrome-sesh or equivalent. Credit to @James B for pointing this out in the comments.

What is Web Security how to disable it in Windows | Mac | Linux

In this post, we are going to see how to disable chrome web security and also run chrome without CORS policy. This post is divided into sections, the first section talks about what is the CORS policy and why is it implemented. The risks of disabling it and more. The second talks about how to disable the Chrome Disable Web Security and How to run chrome without cors policy. So without further delay, let us start it.

What is CORS Policy and what is web security:

CORS stands for Cross-Origin Resouce Sharing. It means that one web site can access the resource from a different web site. Usually, the websites are not directly referred to as websites but they are referred to as Origins. When the resources needed for a website is not available on a single Origin but available on multiple origins the browser has to obtain the resources from multiple origins in order for the website to work as desired.

Jump to:

People Also Search for:

This makes the browser make request resources from different origins and so the term Cross-Origin came into usage. Imagine that the currently open tab in the browser has loaded https://teckangaroo.com. But there is a javascript AJAX in the tab that is requesting to https://abc.com. The browser will block the request made to https://abc.com as it is a different origin from the original https://teckangaroo.com. We can also note that when the tab has loaded https://teckangaroo.com and the AJAX is being made to https://teckangaroo.com (here the protocols are different. The initial protocol is https and the later protocol is http) will also be blocked by the CORS policy as the difference is protocol also means that there is a difference in the Origins as well.

People also search for:

CORS policy prevents malicious websites from exploiting the sensitive information stored in a user’s computer by other websites. Since the CORS policy does not allow requests to a different origin, the malicious websites to make requests to other websites using sensitive information. For example, if a user’s banking credentials are saved locally in the user’s computer by the banking website, the malicious website can not read the credentials and request the bank website to make a transaction behind the back of the user. Thus the CORS policy saves the day and the user.

The CORS policy is one of the policies in web security. Thus enabling the web security will enable the CORS policy. If you want to know more about web security, let us know in the comments or stay tuned to TecKangaroo.

Now that we have seen what is CORS and What is Web Security, let us see how to Chrome Disable Web Security and Run Chrome without CORS.

Run Chrome without CORS Policy in Windows OS:

We can disable CORS Policy in windows by using the following steps.

• Press the start button.

press start button

• Now type CMD as shown in the image.

cmd in windows 10

• Now Right-click the result and select Run as Administrator.

run as administrator

• This will open the command prompt in admin mode.
• We will enter the command that will close all instances of chrome. This is a necessary step and so it is recommended that the user reads all the instructions before proceeding.

taskkill /F /IM chrome.exe

start chrome https://teckangaroo.com/chrome-disable-web-security/ –disable-web-security –user-data-dir=”C:\teckangaroo.com”

After the command successfully executes, Chrome will launch with web security disabled.

If the above steps do not disable web security, there is a good chance that Chrome is not set as a command in Windows. In that case, use the following instructions in order to disable chrome web security.

• Press the start button.

press start button

• Type Chrome.

type chrome in start menu

• Right-click the result and select the open file location.

open the file location

• This will open the location of the Chromeshortcut.
• Now right click on the shortcut and select the open file location.

file location of chrome exe

• This will open the location of the chrome.exe.
• Click on the address bar and type cmd.

click on the address bar type cmd

• This will open the command prompt in the current location.
• Enter the following command into the command prompt to kill all the instances of the chrome.

• Now enter the following command to start chrome with web security disabled.

chrome.exe https://teckangaroo.com/chrome-disable-web-security/ –disable-web-security –user-data-dir=”C:\teckangaroo.com”

After doing the above steps chrome will launch with the web security and CORS policy disabled.

Disable Chrome Web Security in Mac:

Enter the following command into Mac’s terminal to Run Chrome without CORS policy.

open -n -a /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome –args –user-data-dir=”/tmp/chrome_tec_kangaroo” –disable-web-security

Disable Chrome Web Security in Linux:

Enter the following command into the Linux terminal to Run Chrome without CORS policy.

google-chrome –disable-web-security -–allow-file-access-from-files

Conclusion:

In this post, we learned how to Disable Chrome Web Security and also how to run Chrome without CORS policy. We have also learned more about what is Chrome web security and also how it keeps the users safe from malicious web sites. That said, developers can make use of the disabling the chrome web security.

We have seen how to disable web security in Chrome Windows, Mac and also Linux. This will help the users to disable web security and also run chrome without web security.

For more such awesome posts, stay tuned to TecKangaroo.