CORS

Если вы используете веб-приложение, которое обращается к объектам в хранилище из другого домена (например, ваш фронтенд размещен отдельно от хранилища), необходимо настроить политику CORS (Cross-Origin Resource Sharing) — механизма, разрешающего кросс-доменные запросы.

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

Принцип работы CORS

Когда веб-приложение (например, сайт на example.com) пытается получить доступ к ресурсу, размещенному на другом домене (например, test.com), браузер применяет политику безопасности, называемую same-origin policy. Она по умолчанию запрещает такие кросс-доменные запросы. Чтобы обойти это ограничение, используется механизм CORS — Cross-Origin Resource Sharing.

Вот как это работает пошагово:

1. Отправка запроса

Когда браузер обнаруживает кросс-доменные условия, он сначала определяет, является ли запрос простым или предварительным (preflight).

• Простой запрос — это, например, GET или HEAD, без нестандартных заголовков;
• Preflight-запрос — предварительный OPTIONS-запрос, который отправляется, если основной запрос использует методы вроде PUT, DELETE, или имеет нестандартные заголовки.

2. Проверка CORS в бакете

Браузер отправляет preflight-запрос на сервер объектного хранилище S3 с вопросом: «Можно ли с домена example.com выполнить такой-то метод к такому-то ресурсу?»

Объектное хранилище S3 проверяет CORS-конфигурацию бакета. Если конфигурация разрешает такой запрос — в ответ возвращаются нужные заголовки, например:

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST

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

3. Ответ сервера и доступ к данным

Если preflight-запрос прошел успешно или если запрос простой и разрешен, браузер позволяет веб-приложению получить данные. При этом:

• браузер автоматически проверяет наличие заголовков Access-Control-Allow-Origin, Access-Control-Allow-Methods и других;
• без этих заголовков доступ к данным будет заблокирован.

Почему важно настраивать CORS

• Без CORS веб-приложения не смогут обращаться к объектам в хранилище с другого домена;
• Неправильная настройка может открыть доступ к данным для злоумышленников или привести к ошибкам в работе интерфейса.

Хорошая практика — разрешать только нужные домены и только безопасные методы (например, GET, HEAD).

Структура конфигурации CORS

Политика CORS настраивается на уровне каждого бакета в объектном хранилище S3. Это позволяет гибко управлять доступом к объектам из внешних источников, например, с вашего сайта или клиентского приложения.

Конфигурация представляет собой набор правил, описанных в формате XML или JSON. Эти правила можно применить вручную через интерфейс, либо загрузить с помощью инструментов, таких как AWS CLI.

Особенности и ограничения CORS

• В одной конфигурации можно задать до 100 правил CORS;
• Максимальный размер файла конфигурации — 64 КБ;
• Конфигурация применяется на уровне каждого отдельного бакета.

Для добавления конфигурации CORS см. инструкцию Добавить конфигурацию. Для ознакомления с примерами см. Примеры конфигураций CORS в разных форматах.