API - это самая важная часть сегодняшнего сценария веб-разработки (или любой другой разработки). Архитектура на основе API - это парадигма, которая более важна, чем любая другая архитектура в современном мире, главным образом потому, что API-интерфейсы в целом образуют основную часть любого приложения и могут обслуживать различные платформы, такие как мобильные, веб-сайты, виртуальную реальность и многие другие. . Еще одна архитектура, которая также важна для разработки современных приложений, - это архитектура микросервисов, которую гораздо легче проектировать и поддерживать по сравнению с традиционной монолитной архитектурой. У этих двух архитектур встречается общая проблема. Проблема связана с существительным CORS. Обычно, когда веб-разработчики впервые пытаются запачкать руки с API, они в конечном итоге сталкиваются с этим существительным CORS.
Я предполагаю, что читатели встречали это существительное. В противном случае вы можете пропустить этот абзац. В целях «достижения цели» новички (включая меня) пытаются обойти «CORS», реализуя простые обходные пути, которые включают загрузку и реализацию расширения браузера, отправку запроса на прокси-сервер (который является простым однострочником в React), который пересылает запрос и т. д., потому что из-за нашего невежества в целом мы склонны забывать о значении определенных вещей, пытаясь выполнить работу.
В этой статье я собираюсь объяснить CORS таким образом, чтобы вы разработали более крупный и простой из этого механизма.
Расшифровка термина
Поскольку изображение говорит само за себя, если ресурс (например, домен-a) делает запрос (через XMLHttpRequest / Fetch / Axios и т. Д.) На использование API на том же ресурсе, то это запрос с одним и тем же источником.
Но если ресурс выполняет вызов API к другому ресурсу, это называется запросом из разных источников. Запросы с перекрестным происхождением уязвимы для кибератак. Например. Вредоносный сайт может прикрепить файл cookie и сделать запрос на ваш банковский сервер, тем самым поставив под угрозу ваш банковский счет. Здесь запрос, сделанный с помощью, является запросом на разные источники. Следовательно, такие потенциально опасные запросы защищены политикой, которая называется ... Политика одинакового происхождения!
Так что же такое та же политика происхождения?
Политика одинакового происхождения - это важный механизм безопасности, который ограничивает взаимодействие документа или сценария, загруженного из одного источника, с ресурсом из другого источника. Это помогает изолировать потенциально вредоносные документы, уменьшая возможные векторы атак.
Происхождение - это комбинация порта, протокола и хостов.
Веб-браузеры придерживаются той же политики происхождения, чтобы разрешить обмен данными только в том случае, если исходные данные клиента и сервера совпадают.
Таким образом, даже в тех случаях, когда порт будет другим, а другие атрибуты происхождения одинаковы, политика одного происхождения срабатывает и запрещает обмен данными.
Механизм CORS появляется тогда, когда необходимо сделать запрос на перекрестное происхождение. Следовательно, это является благом при обслуживании архитектуры на основе микросервисов, в которой ресурсы могут размещаться в разных местах.
Итак, как происходит совместное использование ресурсов между источниками?
Запрос Cross-Origin можно разделить на два типа
- Простые запросы
- Предварительные запросы
Простые запросы
Простой запрос - это запрос, в котором не инициирован «предполетный» запрос. Он имеет следующие характеристики:
- Разрешены только методы HEAD, POST и GET.
- Никаких дополнительных заголовков, кроме уже существующих, не допускается.
- Заголовок Content-Type имеет значения, отличные от application / x-www-form-urlencoded, multipart / form-data и text / plain.
- Слушатели событий не зарегистрированы ни для одного объекта XMLHttpRequestUpload, используемого в запросе; доступ к ним осуществляется с помощью свойства XMLHttpRequest.upload.
- В запросе не используется объект ReadableStream.
Это очень простой вариант использования, описанный на рисунке ниже.
Предварительные запросы
Любой запрос, который не является простым, подпадает под предварительный запрос. Он назван так потому, что запрос «предварительной проверки» (также называемый запросом «ОПЦИИ») выполняется браузером после того, как он знает, что запрос является предварительным.
Предварительный запрос использует метод OPTIONS и включает заголовки помимо Origin, а именно:
- Доступ-Контроль-Запрос-Метод
- Заголовки запроса-контроля доступа
Оба заголовка задаются методом, который пытается выполнить запрос, и дополнительными заголовками, включенными в запрос.
Следовательно, для поддержки CORS ресурс REST API должен реализовать метод OPTIONS, который может отвечать на предварительный запрос OPTIONS как минимум следующими заголовками ответа, предусмотренными стандартом Fetch:
- Доступ-Контроль-Разрешить-Методы
- Доступ-Контроль-Разрешить-Заголовки
- Доступ-Контроль-Разрешить-Происхождение
Вышеупомянутые заголовки будут присутствовать в ответе, полученном от сервера. Это конфигурации сервера, которые сообщают браузерам, что разрешены соответствующие методы, заголовки и источники.
Что, если я «создаю заголовок» в соответствии с конфигурацией сервера?
Да, ты можешь. Можно создать собственный заголовок и подделать «User-Agent» с помощью соответствующих инструментов на стороне клиента.
Вывод
Вышеупомянутый абзац завершает тот факт, что политика одного и того же происхождения не является своего рода механизмом авторизации. Он реализован браузером как механизм, разрешающий запросы из разных источников и предотвращающий несанкционированный доступ к конфиденциальным данным пользователей, хранящимся в браузере, вредоносными веб-сайтами (см. Подделка межсайтовых запросов). Не более того. Чтобы API-интерфейсы ограничивали доступ неавторизованным пользователям, необходимо использовать ключи API.
Дополнительная литература
Конечное место назначения для веб-разработчиков, страница из MDN Web Docs.
