Cors что это
Перейти к содержимому

Cors что это

  • автор:

Что такое CORS и как его настроить

Познакомьтесь с CORS — важным механизмом безопасности для веб-разработчиков, который позволяет контролировать доступ к серверным ресурсам.

Symbolic representation of CORS mechanism in web development.

Алексей Кодов
Автор статьи
1 июня 2023 в 9:29

CORS, или Cross-Origin Resource Sharing, является механизмом, который позволяет многим ресурсам (например, шрифтам, изображениям, JavaScript) на веб-странице запрашивать данные с другого домена, отличного от домена исходной страницы.

Зачем нужен CORS?

В целях безопасности, браузеры запрещают запросы к другим доменам, используя технику «одного источника» (same-origin policy). Это означает, что веб-страница, загруженная с одного домена, не может получить данные с другого домена без явного разрешения сервера. CORS позволяет серверам указать, с каких доменов разрешено получать данные, обеспечивая безопасность и контроль доступа.

Как настроить CORS?

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

Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type, Authorization 
  • Access-Control-Allow-Origin : указывает, какие домены могут делать запросы к серверу. Значение * разрешает доступ для всех доменов, но для повышения безопасности лучше указать конкретные домены.
  • Access-Control-Allow-Methods : перечисляет методы HTTP, которые разрешено использовать при запросах к серверу.
  • Access-Control-Allow-Headers : указывает, какие HTTP-заголовки допустимы при запросах к серверу.

Настройка CORS может отличаться в зависимости от используемого сервера и языка программирования. Вот примеры настройки CORS для некоторых популярных серверов:

Node.js (Express)

const express = require('express'); const app = express(); app.use((req, res, next) => < res.header('Access-Control-Allow-Origin', '*'); res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS'); res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization'); next(); >); app.listen(3000, () => console.log('Server running on port 3000'));

Python (Flask)

from flask import Flask, request from flask_cors import CORS app = Flask(__name__) CORS(app) if __name__ == '__main__': app.run()

Веб-разработчик: новая работа через 9 месяцев
Получится, даже если у вас нет опыта в IT

Заключение

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

Что такое CORS и как он помогает избежать кражи ваших денег?

image

В этой статье мы расскажем, что из себя представляет политика CORS и что такое CORS в целом, а также чем он полезен для разработчиков.

Для современных веб-приложений загрузка ресурсов с нескольких доменов является обычной практикой. Доступ к этим ресурсам осуществляется с помощью технологии CORS. Например, если вам нужно получить информацию о пользователе на своем сайте «www.mysite.com» с сервера, расположенного на сайте «api.website.com», вы должны отправить запрос на сервер и получить ответ в виде данных JSON.

Что такое CORS?

CORS (Cross-Origin Resource Sharin)совместное использование ресурсов между разными источниками — это механизм, который дает разрешения на загрузку ресурсов из одного источника в другой, сохраняя при этом целостность сайта и защищая его от несанкционированного доступа. Современные браузеры используют это, чтобы определить, какие межсайтовые запросы безопасны.
В целях защиты браузеры ограничивают доступ из скриптов к другим ресурсам, существующим за пределами их домена, с помощью принципа одинакового источника (Same-Origin Policy, политика общего происхождения). Эта политика защищает от кражи личных данных с других веб-серверов или атаки с подделкой межсайтовых запросов (Cross-Site Request Forgery, CSRF).

В данном случае один источник, сайт злоумышленника, пытается получить доступ к ресурсу из источника – сайт онлайн-банка. Same-Origin Policy блокирует доступ киберпреступнику к вашим банковским данным. Однако, правила ограничения домена ограничивает специалистам доступ к ресурсам из разных источников. Поэтому был разработан HTTP-протокол CORS, чтобы сообщать браузеру, что ограниченные ресурсы на веб-странице могут быть запрошены с других доменов. Например, вот возможный сценарий запроса информации из внешнего источника, такого как API (распространенная практика для кода JavaScript на стороне клиента):

  1. Источник ресурса делает предварительный запрос на внешний веб-сервер, используя заголовки CORS;
  2. Затем внешний веб-сервер проверяет этот предварительный запрос, чтобы убедиться, что сценариям разрешено делать запрос;
  3. После проверки внешний веб-сервер отвечает своим собственным набором HTTP-заголовков, которые определяют допустимые методы запроса, источники и настраиваемые заголовки. Ответ сервера может также включать информацию о том, допустимо ли передавать учетные данные, такие как заголовки проверки подлинности.

Для чего мне CORS?

Если вы хотите использовать ресурсы с другого сервера, помимо вашего собственного, вам потребуется использовать CORS.

Некоторые примеры того, что вы можете делать с CORS, включают:

  • Использование веб-шрифтов или таблиц стилей (Google Fonts или Typekit) с удаленного домена;
  • Указание местоположения пользователей на карте через Google Map API: https://maps.googleapis.com/maps/api/js;
  • Отображение твитов из дескриптора Twitter
    API: https://api.twitter.com/xxx/tweets/xxxxx;
  • Использование Headless CMS для управления контентом;
  • Доступ к любому API, размещенному на другом домене или поддомене.

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

Работа CORS начинается, когда сценарий из одного источника отправляет запрос в другой источник. Все это контролируется с помощью предварительного запроса, который обменивается заголовками HTTP-запроса и заголовками ответов, которые называются «CORS-заголовки».

Давайте подробнее рассмотрим, как работают предварительные запросы.

Предварительный запрос

Предварительный запрос (Preflight request) — это дополнительный HTTP-запрос с использованием метода «OPTIONS». Браузер выполняет это для каждого небезопасного запроса, предназначенного для изменения данных, например запросов POST, PUT или DELETE.

Предварительный запрос является стандартным поведением для современных веб-браузеров. Ожидаемый ответ от приложения — это ответ, содержащий CORS-заголовки с правильными инструкциями.

Пример предварительного запроса:

Здесь мы видим несколько определенных HTTP-заголовков. Это одни из наиболее распространенных CORS-заголовков, используемых в запросах браузера и ответах сервера:

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Headers

Рассмотрим подробнее, как работают эти CORS-заголовки.

Access-Control-Allow-Origin

Представьте себе следующий сценарий: я хочу разрешить приложению, размещенному на https://mywebsite.com, доступ к ресурсу.

В этом случае мне нужно указать следующее:

Кроме того, добавление настраиваемого заголовка Access-Control-Allow-Origin в объектных хранилищах, таких как AWS S3 или Google Storage, оптимизирует пропускную способность, оптимизирУЕТ использование ресурсов и ускорит извлечение данных.

Access-Control-Allow-Origin также можно использовать, если другой сайт полностью копирует ваш, что негативно влияет на SEO вашего сайта. Таким образом, контент вашего веб-сайта не будет отображаться на зеркальном сайте. Но вы также можете подать заявление DMCA Takedown Notice, чтобы удалить свой контент с другого сайта, поскольку злоумышленник может обойти политику Access-Control-Allow-Origin с помощью прокси-сервера.

Проблемы безопасности с Access-Control-Allow-Origin

Довольно часто можно найти приложения, использующие эту нотацию для Access-Control-Allow-Origin:


Символ «*» указывает браузеру разрешить доступ к ресурсу из любого источника, фактически отключая политику Same-Origin Policy. Это означает, что браузер не будет фильтровать источники. Любой код на любом сайте может сделать запрос к ресурсу (включая вредоносные домены).

Кроме того, символ «*» широко используется хакерами, особенно для веб-скиммеров. AJAX-запросы отправляются со страниц оформления заказа на взломанных сайтах на вредоносные серверы, которые передают украденные платежные реквизиты.

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

Часть эксфильтрации скиммера для кредитных карт JavaScript.

Вот пример CORS-заголовков, используемых для URL-адреса эксфильтрации веб-скиммера:

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

Access-Control-Allow-Methods

При разработке RESTful API большинство конечных точек будут принимать методы GET, POST, PUT, PATCH и DELETE.

С помощью заголовка Access-Control-Allow-Methods вы можете точно указать, какие HTTP-методы ваше приложение должно предоставлять внешним источникам. Это может помочь снизить риск любой нежелательной активности в вашей среде.

Этот заголовок резервирует использование POST, PUT, PATCH и любого типа метода HTTP, который используется для изменения содержимого приложения в вашем домене. Это позволяет внешним приложениям использовать GET-запросы только для чтения ресурсов.

Access-Control-Allow-Headers

Цель заголовка Access-Control-Allow-Headers — разрешить пользовательские заголовки. Например, приложение, которое использует “X-My-Header”, должно ответить на предварительный запрос с этим заголовком в своем списке разрешений.

Если заголовок не разрешен, консоль разработчика отобразит следующую ошибку:

X header field authorization is not allowed by Access-Control-Allow-Headers in preflight response.

Как включить CORS на моем сервере?

Вы можете легко изменить настройки CORS на любом сервере Apache, изменив файл «.htaccess».

  1. Откройте файловый менеджер или sFTP;
  2. Перейдите в каталог вашего веб-сайта;
  3. Откройте свой файл «.htaccess» или создайте новый;
  4. Включите в содержимое файла директивы CORS.

Для пользователей NGINX включение CORS осуществляется с помощью основного модуля Headers.

Как включить CORS на WordPress

1. Настройте функцию CORS-заголовка

Добавьте следующий код в файл «functions.php».

Здесь осуществляется проверка того, находится ли ваша среда в рабочем режиме. Если да, то значение «$origin_url» изменится на ваш действующий домен.

2. Включите функцию CORS

Добавьте следующее действие «rest_api_init». Оно добавляется непосредственно под функцией «initCors», которую мы только что создали.

3. Разрешите поддержку нескольких источников

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

Как избежать использования CORS?

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

Безопасность веб-сайта с помощью CORS

CORS — это способ улучшить защиту вашего веб-приложения на стороне клиента, но его нельзя использовать в качестве единственного уровня защиты.

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

Примените следующие меры защиты для вашего сайта:

  • не используйте подстановочный знак «*», чтобы не допустить каждому загружаемому сценарию связываться с ресурсом;
  • проверяйте все заголовки запросов управления доступом по соответствующим спискам доступа;
  • попробуйте простое, но безопасное сравнение строк с массивом доверенных значений, чтобы снизить риск;
  • используйте как можно больше уровней защиты;
  • регулярно применяйте обновления с исправлениями уязвимостей ПО;
  • настройте правила управления доступом;
  • используйте брандмауэр веб-сайта.

Цифровые следы — ваша слабость, и хакеры это знают. Подпишитесь и узнайте, как их замести!

Что такое CORS

CORS расшифровывается как Cross-Origin Resource Sharing. Это механизм браузера, который позволяет определить список ресурсов, к которым страница может получить доступ. Он необходим для обеспечения безопасности и защиты пользователей от злоумышленников при использовании HTTP протокола.

По умолчанию, сайты могут запрашивать ресурсы только со своего origin . Такое ограничение называется Same-Origin Policy. CORS расширяет Same-Origin Policy, позволяя получать доступ к ресурсам с разных доменов.

origin — это комбинация протокола, домена и порта (если он указан). Например, doka . guide — это домен, а https : / / doka . guide — origin .

Настройка доступа должна происходить как со стороны браузера, так и со стороны сервера.
Это означает, что и браузер, и сервер должны быть настроены на разрешение или запрет доступа к ресурсам с других origin .

Как работает

Скопировать ссылку «Как работает» Скопировано

Рассмотрим пример работы CORS без дополнительной настройки:

Пользователь открывает страницу сайта doka . guide . Страница отправляет запрос к стороннему источнику api . example . com .
Браузер сравнивает origin и понимает, что api . example . com — сторонний origin для нашего сайта, из-за чего блокирует запрос. Причём запрос может быть заблокирован и в рамках одного домена, например у http : / / doka . guide и https : / / doka . guide origin будет отличаться из-за несовпадения протоколов.

Такие запросы с сайта на сайт называются перекрёстными.

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

Настройка

Скопировать ссылку «Настройка» Скопировано

Для настройки CORS со стороны сервера используются специальные заголовки запроса:

  • Access — Control — Allow — Origin — указывает на origin , откуда на сервер разрешены запросы.
  • Access — Control — Allow — Methods — указывает, какие HTTP-методы разрешены для запросов на сервер. Например, GET , POST , DELETE .
  • Access — Control — Allow — Headers — определяет, какие заголовки могут быть использованы в ответе от сервера, которые не являются стандартными для HTTP.
  • Access — Control — Allow — Credentials — указывает, разрешено ли отправлять cookie и авторизационные данные вместе с запросом на сервер. Для разрешения используется значение true .
  • Access — Control — Max — Age — определяет максимальное время, в течение которого должны кэшироваться предыдущие ответы на запросы предварительной проверки CORS.
  • Access — Control — Expose — Headers — определяет список заголовков, которые могут быть доступны на клиентской стороне.

Также есть заголовок для настройки со стороны браузера:

  • Origin — указывает на комбинацию домена, порта и протокола, откуда на сервер поступает запрос.

И заголовки для настройки предварительных запросов:

  • Access — Control — Request — Method — определяет метод запроса, который будет использоваться в основном запросе.
  • Access — Control — Request — Headers — используется для указания заголовков, которые будут использоваться в основном запросе.

Предварительные запросы

Скопировать ссылку «Предварительные запросы» Скопировано

Предварительный запрос — это дополнительный HTTP запрос, который отправляется браузером перед основным запросом.

Когда страница запрашивает данные с другого origin , браузер отправляет предварительный запрос OPTIONS на сервер, чтобы узнать, разрешены ли такие запросы. При повторном запросе на тот же origin , запрос OPTIONS может и не отправляться, а все данные будут получены из кеша.

При отправке запроса на api . example . com , браузер проставит заголовок Origin , сформирует запрос в определённом формате и отправит его на сервер:

OPTIONS / HTTP/1.1 Host: api.example.com Origin: doka.guide

Если сервер запрещает доступ к ресурсу, то в результате запроса в браузере мы увидим ошибку.

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

Access — Control — Allow — Origin : doka . guide

Такая запись означает, что сервер разрешает доступ с домена doka . guide .

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

Access — Control — Allow — Origin : doka . guide github . com stackoverflow . com

Или задать маску:

  • * . site . com — для разрешения доступа с любого поддомена site . com .
  • * — для разрешения доступа отовсюду.

Однако необходимо быть осторожным при использовании этого заголовка, так как неправильная конфигурация может привести к уязвимостям безопасности. Например, если сервер отправляет Access — Control — Allow — Origin : * , это означает, что любой origin может получить доступ к ресурсам на сервере. Это может привести к возможности выполнения атак, например, CSRF и других.

Важно помнить

Скопировать ссылку «Важно помнить» Скопировано

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

Понимание CORS

Правило одного источника является важным принципом обеспечения безопасности, реализованное web браузерами для предотвращения выполнения JavaScript кодом запросов к другим источникам(т.е. к другим доменам), а не к тому, с которого он передан. Несмотря на эффективность такого правила, оно также ограничивает в законных взаимодействиях между сервером и клиентами из надежных источников.

Cross-Origin Resource Sharing (CORS) является техникой для ослабления правила одного источника, позволяя JavaScript на web странице обрабатывать ответ от REST API от другого источника.

Обработка простых CORS запросов

В простейшем случае, междоменные взаимодействия начинаются с запроса GET, POST или HEAD к ресурсу на сервере. В данном случае, тип содержимого POST запроса ограничен application/x-www-form-urlencoded , multipart/form-data или text/plain . Запрос включает заголовок Origin , который указывает на происхождение клиентского кода.

Сервер будет учитывать Origin запроса и принимать или отказывать в обработке запроса. Если сервер принял запрос, то он ответит запрашиваемым ресурсом в заголовке Access-Control-Allow-Origin . Этот заголовок будет указывать клиенту с каким происхождением клиента будет разрешен доступ к ресурсу. Принимая во внимание, что Access-Control-Allow-Origin соответствует Origin запроса, браузер разрешит запрос.

С другой стороны, если Access-Control-Allow-Origin отсутствует в ответе или если его нет в Origin запроса, то браузер не разрешит запрос.

К примеру, предположим, что клиентский код расположен на foo.client.com и отправляет запрос на bar.server.com:

GET /greeting/ HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1 Accept: application/json, text/plain, */* Referer: http://foo.client.com/ Origin: http://foo.client.com

Заголовок Origin говорит серверу, что клиентский код создан в http://foo.client.com. Так он проверяет правила одного источника и определяет, что он может обработать запрос. Ответ может выглядеть примерно так:

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Date: Wed, 20 Nov 2013 19:36:00 GMT Server: Apache-Coyote/1.1 Content-Length: 35 Connection: keep-alive Access-Control-Allow-Origin: http://foo.client.com [response payload]

Access-Control-Allow-Origin указывает на то, что «http://foo.client.com» разрешен доступ, но не другим источникам.

Дополнительно Access-Control-Allow-Origin может быть установлен в «*», указывая на доступность всем. Это считается небезопасной практикой, кроме тех особых случаев, где API полностью публично и предназначено для использования любым клиентом.

Предполетные запросы

Если запрос может оказать влияние на пользовательские данные, то простого запроса недостаточно. Вместо этого, предполентый CORS запрос отправляется в перед отправкой необходимого запроса, чтобы гарантировать безопасность отправки запроса. Предполетные запросы необходимы в тех случаях, когда любой HTTP метод, отличный от GET, POST, HEAD или если тип содержимого POST запроса отличен от application/x-www-form-urlencoded , multipart/form-data или text/plain . Также, если запрос содержит любые собственные заголовки, то необходим предполетный запрос.

Некоторые JavaScript библиотеки, такие как AngularJS или Sencha Touch, отправляют предполетные запросы на любой дочерний запрос. Этот подход пожалуй безопаснее, потому что он не предполагает, что сервис придерживается семантик HTTP метода(т.е. GET endpoint моглда быть написана с побочными эффектами).

К примеру, предположим, что клиент, расположенный на foo.client.com, выполняет DELETE запрос к ресурсу не bar.server.com. Предполетный запрос принимает вид OPTIONS запроса со следующими заголовками:

OPTIONS /resource/12345 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1 Access-Control-Request-Method: DELETE Access-Control-Request-Headers: origin, x-requested-with, accept Origin: http://foo.client.com

Предполетный запрос фактически спрашивает сервер о доступности DELETE запроса без фактической отправки самого DELETE запроса. Если сервер разрешает такой запрос, то он ответит предполетному запросу примерно так:

HTTP/1.1 200 OK Date: Wed, 20 Nov 2013 19:36:00 GMT Server: Apache-Coyote/1.1 Content-Length: 0 Connection: keep-alive Access-Control-Allow-Origin: http://foo.client.com Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE Access-Control-Max-Age: 86400

Ответ предполетному запросу указывает(в заголовке Access-Control-Allow-Methods ) на то, что клиенту доступен DELETE запрос к передаваемому ресурсу. Заголовок Access-Control-Max-Age указывает на то, что этот предполетный ответ действует 84600 секунд или 1 день, после которого должен быть выполнен новый предполетный запрос.

В то же время клиенту будет доступно отправка настоящего DELETE запроса к ресурсу.

С оригинальным текстом урока вы можете ознакомиться на spring.io.

Учебные материалы

  • Обработка ответа RESTful Web сервиса с использованием jQuery
  • Обработка ответа RESTful Web сервиса с использованием rest.js
  • Обработка ответа RESTful Web сервиса с использованием Backbone.js
  • Обработка ответа RESTful Web сервиса с использованием AngularJS
  • Обработка ответа RESTful Web сервиса с использованием Sencha Touch

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *