Laravel: Погружение в CORS
Laravel уже давно поддерживает CORS; однако до более поздних версий это было только из сторонних пакетов. Давайте углубимся в CORS в Laravel, что это такое и почему это важно.
CORS означает Cross-Origin Resource Sharing — Совместное использование ресурсов разных источников. Это механизм позволяющий безопасно отправлять запросы к домену, отличного от вашего. Он определяет набор заголовков, которые сервер может использовать для управления тем, какие источники могут получить доступ к его ресурсам. Но что это значит для вас?
Как человек, который создаёт множество API, я привык к CORS. На данный момент это стало второй натурой. Laravel по умолчанию имеет встроенную поддержку CORS, где он будет читать из config/cors.php для программного создания правил защиты на основе настроенных значений. Давайте пройдёмся по параметрам в этом файле, чтобы увидеть, что они значат для вас.
Пути
Первая опция — paths, которая по умолчанию имеет следующее значение:
'paths' => ['api/*', 'sanctum/csrf-cookie'],В этой опции мы сообщаем CORS middleware, чтобы оно соответствовало любым перечисленным запросам и позволяло CORS перейти к следующей проверке. Если входящий запрос не соответствует ни одному шаблону, который мы добавляем в конфигурацию, мы автоматически блокируем любые запросы от внешних хостов.
Методы
Следующая опция — allowed_methods, разрешённые методы, которые по умолчанию настроена следующим образом:
'allowed_methods' => ['*'],По умолчанию Laravel разрешает передавать любой метод извне, а это означает, что интеграция API не требует каких-либо особых соображений. Здесь вы можете быть настолько строгим или расслабленным, насколько захотите. Это полностью зависит от вас. Я обычно оставляю значение по умолчанию, так как большинство API, которые я обычно создаю, в некоторых отношениях требуют полного внешнего контроля. Если бы мы изменили это на:
'allowed_methods' => ['GET', 'POST','PUT','PATCH'],Это будет означать, что мы хотим явно отклонить любые внешние запросы, которые явно являются запросом DELETE или запросом не указанным в конфигурации CORS. Если у вас публичный API только для чтения, вы, скорее всего, настроите его по другому.
Источники
Далее мы смотрим на 'allowed_origins', разрешённые источники, которые по умолчанию настроены так:
'allowed_origins' => ['*'],По умолчанию мы говорим, что разрешаем соединения или запросы из любого источника (также известного как IP-адрес или сервер). Если бы мы создавали внутренний API, мы бы хотели настроить их либо на диапазон IP-адресов, либо ограничить определёнными домена. Это помогает защититься от людей, отправляющих запросы оттуда, откуда вы, возможно, этого не хотите. Опять, если ваш API является публичным, вы, скорее всего, оставите его как есть. Помните об этом параметре, если у вас возникнут проблемы с CORS при интеграции с вашим API.
Вы можете использовать дополнительную часть конфигурации, чтобы быть менее конкретным и больше опираться на соответствие регулярным выражениям. Это шаблоны разрешённых источников, где вы можете добавить регулярное выражение для проверки происхождения запроса, чтобы увидеть, принимаются они или отклоняются. По умолчанию это пустой массив, так как здесь нужно быть осторожным:
'allowed_origins_patterns' => [],Заголовки
Вы можете быть настолько строгим или расслабленным, насколько вам нужно, с заголовками, когда дело доходит до конфигурации CORS. Эта часть конфигурации позволяет указать, какие заголовки из сторонних источников разрешены при поступлении входящего запроса. Допустим, вы хотите быть очень конкретным, чтобы внешние стороны могли делать запросы только в определённых типах контента или принудительно принимать определённые типы контента. Это маловероятно, но хороший пример. В некоторых API, особенно несколько лет назад, я добавлял middleware, которое проверяло, принимают ли они 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, потому что вы не хотите подвергать себя и, соответственно, своих пользователей любым потенциальным атакам из-за неправильной конфигурации.