Найти в Дзене
Laravel Topsite Web

Совместное использование ресурсов разных источников (CORS) в Laravel

Оглавление

Узнайте, что это такое Laravel CORS, и раскройте его потенциал для бесперебойного совместного использования ресурсов из разных источников.

Laravel довольно долгое время поддерживал CORS, однако до более поздних версий он был только из сторонних пакетов. Давайте погрузимся в CORS в Ларавеле, что это такое и почему это важно.

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

Как человек, который создает множество API-интерфейсов, я очень привык к CORS. В Laravel, по умолчанию, встроена поддержка CORS, откуда он будет считывать данные config/cors.php для программного создания правил защиты на основе настроенных значений. Давайте пройдемся по параметрам в этом файле, чтобы понять, что они значат для нас.

Пути

Наш первый вариант — это пути, которые по умолчанию имеют следующее:

'paths' => ['api/*', 'sanctum/csrf-cookie'],

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

Методы

Наш следующий вариант — разрешенные методы, которые по умолчанию настраиваются следующим образом:

'allowed_methods' => ['*'],

По умолчанию Laravel позволит передавать любой метод извне, а это означает, что интеграция API не требует каких-либо особых соображений. Здесь вы можете быть настолько строгими, на сколько хотите. Это полностью зависит от вас. Обычно я сохраняю здесь значение по умолчанию, так как большинство API, которые я обычно создаю, в некоторых отношениях хотят полного внешнего контроля. Если мы изменим это на:

'allowed_methods' => ['GET', 'POST','PUT','PATCH'],

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

Источники

Далее мы рассмотрим разрешенные источники, которые по умолчанию настроены следующим образом:

'allowed_origins' => ['*'],

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

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

'allowed_origins_patterns' => [],

Заголовки

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

Допустим, вы хотите быть очень конкретными, чтобы внешние стороны могли делать запросы только в определенных типах контента или обеспечивать принятие определенных типов контента. Это маловероятно, но хороший пример. В некоторых API, особенно несколько лет назад, я добавлял промежуточное программное обеспечение приложений, которое проверяло, принимают ли они JSON, и отклоняло с предупреждением, если его не было на месте. Мы можем сделать то же самое здесь, но только для третьих лиц. Однако по умолчанию в Laravel выглядит следующим образом:

'allowed_headers' => ['*'],

Разоблачение заголовков

Скорее всего, вам это не понадобится, но если вы это сделаете, потребуется много времени, чтобы понять, что вам это нужно! Конфигурация по умолчанию выглядит следующим образом:

'exposed_headers' => [],

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

Допустим, у вас есть заголовки, которые не являются стандартными, такие как: X-VAPOR-ENCODE или X-GITHUB-ID или что-то в этом роде, по умолчанию они будут удалены при запросах CORS, что, в свою очередь, может вызвать непреднамеренные побочные эффекты, о которых вы не знали.

Максимальный возраст

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

'max_age' => 0,

По умолчанию мы настраиваем это так, чтобы клиенты ничего не кэшируют из нашего приложения.

Полномочия

Наконец, у нас есть вариант учетных данных поддержки. Эта опция по умолчанию имеет значение false:

'supports_credentials' => false,

Здесь мы настраиваем, хотим ли мы разрешить аутентификацию сторонних производителей. Это то, к чему следует быть очень внимательным, потому что если вы установите значение true, люди смогут войти в систему и получить данные аутентификации. Если мы установим это на true, то вы откроетесь для потенциальных фишинговых атак на ваших пользователей, что может привести к дальнейшим проблемам. Если вам нужно установить значение true, убедитесь, что другие параметры точны, чтобы вы могли контролировать, кто может это сделать. Последнее, что вы хотите сделать, это разрешить все запросы из любого источника, который поддерживает учетные данные!

Заключение

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