Из этого руководства вы узнаете, как использовать возможности Laravel CORS. Узнайте, что это такое, и раскройте его потенциал для беспрепятственного совместного использования ресурсов разных источников.
Laravel уже давно поддерживает CORS; однако до более поздних версий это было только из сторонних пакетов. Давайте разберемся что такое CORS в Laravel, и почему это важно.
CORS расшифровывается как Cross-Origin Resource Sharing (Совместное использование ресурсов разных источников). Это механизм, который позволяет вам безопасно отправлять запросы к домену, отличному от вашего собственного. Этот механизм выбирает набор заголовков, которые сервер может использовать для управления тем источникам, которые могут получить доступ к его ресурсам. Но что это значит для вас?
Как человек, который создает множество API, я очень привык к CORS. На данный момент это стало второй натурой. Laravel по умолчанию имеет встроенную поддержку CORS, откуда он будет читать config/cors.php для программного построения правил защиты на основе настроенных значений. Давайте пройдемся по параметрам в этом файле, чтобы увидеть, что они для нас значат.
Пути
Наш первый вариант это пути, которые по умолчанию имеет следующие параметры:
'paths' => ['api/*', 'sanctum/csrf-cookie'],В этом варианте мы сообщаем промежуточному программному обеспечению CORS, чтобы оно соответствовало любым перечисленным здесь запросам и позволяло CORS перейти к следующей проверке. Если входящий запрос не соответствует какому-либо шаблону, который мы добавляем в нашу конфигурацию, мы автоматически блокируем любые запросы от внешних хостов.
Методы
Наш следующий параметр - разрешенные методы, который по умолчанию настроены следующим образом:
'allowed_methods' => ['*'],По умолчанию Laravel разрешает передавать любой метод извне, это означает, что интеграция API не требует каких-либо особых соображений. Вы можете выбрать любой вариант на ваше усмотрение. Я обычно оставляю здесь значение по умолчанию, так как большинство API, которые я обычно создаю, в некоторых случаях требуют полного внешнего управления. Если бы мы изменили это на:
'allowed_methods' => ['GET', 'POST','PUT','PATCH'],Это означало бы, что мы хотим отклонить любые внешние запросы, которые являются DELETE запросами или запросоми, не указанные в конфигурации CORS. Если у вас есть общедоступный API только для чтения, вы, скорее всего, настроите его по-другому.
Источники
Далее мы рассмотрим источники, которые по умолчанию настроены следующим образом:
'allowed_origins' => ['*'],Мы говорим, что по умолчанию мы разрешаем соединения или запросы из любого источника (также известного как IP-адрес или сервер). Если бы мы создавали внутренние API, мы бы хотели настроить их либо на диапазон IP-адресов, либо ограничить это определенными доменами. Это помогает защитить вас от людей, отправляющих запросы оттуда, откуда вы, возможно, этого не желаете. Опять же, если ваш API является общедоступным, вы, скорее всего, оставите его как есть. Если у вас возникнут проблемы с CORS при интеграции с вашим API, помните об этом параметре.
Вы можете использовать дополнительную часть конфигурации, чтобы быть менее конкретным и больше опираться на соответствие регулярным выражениям. Это шаблоны разрешенных источников, где вы можете добавить регулярное выражение для проверки происхождения запроса, чтобы увидеть, принимаются они или отклоняются. По умолчанию это пустой массив, здесь нужно быть осторожным:
'allowed_origins_patterns' => [],Заголовки
Вы можете выбрать любой вариант с заголовками, когда дело доходит до конфигурации CORS. Эта часть конфигурации позволяет вам установить, какие заголовки разрешены из сторонних источников, при поступлении запроса. Допустим, вы хотите четкого выполнения того, чтобы внешние стороны могли делать запросы только в определенных типах контента или принудительно принимать определенные типы контента. Это конечно маловероятно, но это хороший пример. Некоторое время назад, в некоторые API, я добавлял промежуточное программное обеспечение приложений, которое проверяло, принимают ли они JSON, и с предупреждением отклоняло бы, если бы его не было на месте. Мы можем сделать то же самое и здесь, но только для третьих лиц. Однако по умолчанию в Laravel это выглядит следующим образом:
'allowed_headers' => ['*'],Раскрытие заголовков
Разоблачение заголовков — это интересно. Скорее всего, он вам не понадобится, но если он нужен, для этого потребуется время! Конфигурация по умолчанию выглядит следующим образом:
'exposed_headers' => [],Вам нужно понять, что сюда добавить, кто или что с вами интегрируется. Обычно проблемы CORS здесь связаны с правилами браузера в отношении CORS или CORS запросов, когда заголовки удаляются, поскольку их считают небезопасными. Допустим, у вас есть заголовки, которые не используются по умолчанию, например: X-VAPOR-ENCODE или X-GITHUB-ID или что-то в этом роде, по умолчанию они будут удалены из запросов CORS, что, в свою очередь, может вызвать непреднамеренные побочные эффекты, о которых вы не подозревали.
Максимальный возраст
Мы можем сделать настройку того, как долго клиенты смогут кэшировать ресурсы для использования этой опции в конфигурации CORS.
'max_age' => 0,По умолчанию мы настраиваем это так, чтобы клиенты ничего не кэшировали из нашего приложения. Это гибкая настройка, поскольку только такие интеграции, как браузеры, будут полностью соблюдать это условие.
Учетные данные
Наконец, у нас есть опция учетных данных поддержки. Этот параметр по умолчанию имеет значение false:
'supports_credentials' => false,В этом случае выполняя настройки мы должны учитывать, хотим ли мы разрешить аутентификацию из сторонних источников. Нужно быть очень внимательным, потому что, если вы установите для этого параметра значение true, люди смогут войти в систему и получить обратно данные аутентификации. Если мы установим для этого параметра значение true, то вы откроете себя для потенциальных фишинговых атак на ваших пользователей, что может привести к дальнейшим проблемам. Если вам нужно установить для него значение true, убедитесь, что другие параметры точны, чтобы вы могли контролировать, кто может это делать. Последнее, что вам нужно сделать, это разрешить все запросы из любого источника, который поддерживает учетные данные!
Мы вам предоставили пошаговый обзор того, что можно сделать с конфигурацией и что означает каждая опция для вас и вашего приложения. Будьте предельно внимательны при настройке конфигурации и соблюдении правил CORS, чтобы не подвергать себя и своих пользователей любым потенциальным атакам из-за неправильной конфигурации.
Оригинал статьи - https://laravel-news.com/diving-into-cross-origin-resource-sharing