Возможность

CORS Policy Rule

Освободите команды API от ошибок CORS в браузере — управляйте заголовками preflight и ответа из единого правила.

TR7 CORS Policy Rule управляет заголовками CORS, необходимыми для cross-origin доступа к API, на уровне ADC, не затрагивая код приложения. Origin allow-list, разрешённые методы, разрешённые заголовки, поведение credentials и длительность кэша preflight — всё это может быть определено в рамках единой политики. Этот подход не позволяет командам frontend и API писать отдельный CORS-код для каждого сервиса. Приложение генерирует ответ; TR7 добавляет ожидаемые браузером CORS-заголовки как центральную политику, отвечает на preflight-запросы надлежащим образом и дополняет необходимые заголовки на стороне фактического ответа. Политика может применяться на уровне vService, host, path или разных условий трафика. Это означает, что публичные API, admin API, partner API и internal API могут работать с разным поведением CORS на одном устройстве. Результат: TR7 убирает управление CORS из настроек фреймворков приложений и превращает его в центральное, поддающееся аудиту и повторно используемое правило на уровне безопасности API и доставки приложений.

Настраиваемые параметры CORS: Origin, Methods, Headers, Credentials, Max-Age

Управляемые типы запросов: OPTIONS preflight и фактический ответ

Центральное правило — согласованная политика CORS для всех vService и путей

Когда CORS оставлен на откуп коду приложения, каждый API становится отдельной проблемой совместимости с браузером.

Современные веб-приложения, как правило, обращаются к API, работающим на разных доменах, субдоменах или портах. Браузер ограничивает этот доступ через политику CORS. Если API не возвращает правильные заголовки Access-Control-Allow-*, запрос блокируется браузером, даже если он успешно выполняется на стороне сервера. Результат — неработающее приложение для пользователя и трудно диагностируемая ошибка CORS для команды.

В большинстве организаций эта проблема распределяется по командам приложений. Каждый сервис определяет своё поведение Origin, Method, Header, Credentials и Max-Age отдельно в собственных настройках фреймворка. По мере роста числа сервисов становится неизбежным, что одна и та же политика CORS в итоге написана по-разному в разных приложениях.

Неверные настройки CORS также создают риски безопасности. Во время разработки открываются wildcard-Origin как быстрое решение, предоставляются слишком широкие разрешения вместе с credentials или поведение preflight оставляется неполным. Когда такие настройки попадают в production, поверхность API оказывается излишне открытой.

Правильный подход — управлять политикой CORS как центральным правилом запроса/ответа. Origin allow-list, credentials, разрешённые методы, разрешённые заголовки и кэш preflight — всё это должно быть определено в одном месте, а не разбросано по коду приложений.

TR7 CORS Policy Rule реализует эту модель: делает заголовки CORS для preflight и фактического ответа управляемыми из единого действия на уровне vService или path.

Наш подход

Политика CORS TR7 объединяет валидацию origin, управление preflight, заголовки ответа и условную логику применения в одном правиле.

Origin allow-list принимает только разрешённые источники

TR7 может сравнивать входящее значение Origin с определённым allow-list. Список может содержать фиксированные домены или более гибкие совпадения на основе regex.

Preflight-запросы обрабатываются без добавления нагрузки на приложение

TR7 может генерировать необходимые заголовки CORS для OPTIONS preflight-запросов. Это позволяет приложению фокусироваться только на реальном API-запросе.

Заголовки фактического ответа дополняются в соответствии с ожиданиями браузера

Заголовки такие как Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials и Max-Age добавляются через центральную политику. Совместимость с браузером становится независимой от кода приложения.

Политики на уровне vService и path разделяют разные API

Разные поверхности API на одном устройстве могут работать с разным поведением CORS. Публичный API может быть шире, partner API — уже, а internal API — управляться собственным allow-list.

Возможности

CORS Policy Rule упрощает процесс публикации API, обеспечивая управление preflight и фактическим ответом из единого действия.

Единое правило управляет заголовками CORS для preflight и фактического ответа

Действие CORS TR7 может обрабатывать как OPTIONS preflight-запросы, так и реальные заголовки ответа API в рамках одной политики. Это не позволяет командам приложений кодировать поведение preflight и фактического ответа отдельно. Политика определяется один раз и применяется к соответствующему vService или path. Операции могут централизованно управлять поведением CORS.

Origin allow-list разрешает только доверенные источники frontend

Разрешённые значения Origin могут быть явно определены в политике CORS. Этот список может состоять из конкретных доменов, шаблонов субдоменов или совпадений на основе regex. Доступ предоставляется доверенным приложениям frontend без необходимости использовать wildcards. Доступ браузера обеспечивается без излишнего раскрытия поверхности API нежелательным источникам.

Поиск origin с поддержкой regex упрощает структуры с несколькими субдоменами

Организации часто используют структуры субдоменов на основе клиентов, тенантов или сред. Поиск origin на основе regex позволяет установить контролируемую политику разрешений без перечисления каждого субдомена индивидуально. Например, могут быть приняты frontend тенантов в рамках конкретного дерева доменов. Эта гибкость обеспечивает масштабируемое управление CORS без открытия wildcards.

Переключатель credentials обеспечивает контролируемое использование cookie и auth-заголовков

Поведение Access-Control-Allow-Credentials может переключаться централизованно. Эта настройка критична для frontend, работающих с cookie или заголовками Authorization. Когда credentials включены, Origin allow-list следует держать узким. TR7 перемещает это поведение из разрозненных настроек команд приложений в единую точку политики.

Список разрешённых методов ограничивает поверхность API на уровне браузера

Методы такие как GET, POST, PUT, PATCH, DELETE или OPTIONS могут быть определены в рамках политики. Браузер принимает только разрешённые методы во время preflight. Это уточняет, какие типы операций API раскрывает клиентской стороне. Безопасность и опыт разработчиков управляются из одного списка.

Список разрешённых заголовков управляет использованием пользовательских заголовков

Authorization, Content-Type, X-Request-ID или пользовательские заголовки приложений могут быть определены в allow-list. Браузер проверяет во время preflight-запроса, могут ли использоваться эти заголовки. Отсутствующие разрешения заголовков приводят к ошибкам frontend; слишком широкие разрешения заголовков создают ненужное раскрытие поверхности. TR7 управляет этим балансом централизованно.

Кэширование preflight max-age снижает нагрузку запросов браузера

Значение Access-Control-Max-Age контролирует, как долго браузер кэширует результат preflight. Подходящее значение max-age снижает OPTIONS-трафик для частых API-вызовов. Слишком короткое значение создаёт ненужные preflight-накладные расходы; слишком длинное означает, что изменения политики могут отражаться с опозданием. TR7 делает эту настройку настраиваемой под потребности каждого сервиса.

Применение на уровне vService обеспечивает отдельный стандарт CORS для каждого API

Каждый vService может иметь собственную политику CORS. Публичный API, partner API, admin API или internal API могут работать с разными списками origin и методов. Эта модель предотвращает применение единой глобальной настройки CORS слишком широко ко всем API. Оператор устанавливает границы безопасности на уровне сервиса.

Применение на уровне path обеспечивает разное поведение эндпоинтов в рамках одного сервиса

Разные политики CORS могут применяться к разным путям в рамках одного vService. Например, `/public/api` может работать с более широким списком origin, а `/admin/api` — только с конкретным управленческим frontend. Это разделяет поверхность API на уровне эндпоинта. Не нужно писать сложные CORS if-блоки в коде приложения.

Условное поведение CORS может быть установлено с движком правил трафика

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

Стандарты CORS применяются без зависимости от фреймворка приложения

Когда поведение CORS распределено по фреймворкам приложений, каждый язык и сервис требует разной логики конфигурации. TR7 перемещает это поведение на уровень ADC, снижая зависимость от приложений. Команды приложений фокусируются только на бизнес-логике API, пока стандарт CORS поддерживается централизованно. Legacy и современные сервисы могут публиковаться под одной моделью политики.

Аудит и централизованное управление изменениями снижают риск CORS

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

Операционная глубина

CORS Policy Rule работает совместно с сопоставлением origin, поведением credentials, ответом на preflight, балансом max-age, областью path и видимостью аудита.

Сопоставление origin

Входящее значение Origin может сравниваться с allow-list или правилами regex. При отсутствии совпадения заголовки CORS могут не добавляться или может применяться поведение отклонения, как того требует политика. Рекомендуется использовать явный список вместо wildcard.

Поведение credentials

Когда credentials активны, идентификационные данные, такие как cookie и auth-заголовки, могут использоваться в cross-origin запросах. В этом режиме важно, чтобы политика Origin была узкой и чётко определённой. Credentials вместе с wildcard Origin — небезопасное допущение.

Ответ на preflight

OPTIONS-запросы отправляются браузером для проверки разрешений на методы и заголовки. TR7 может централизованно управлять ответом на preflight, генерируя необходимые заголовки Allow-*. Это снижает нагрузку на бэкенд-сервис от ненужных OPTIONS-запросов.

Баланс max-age

Длительность кэша preflight требует баланса между производительностью и актуальностью политики. Большая длительность генерирует меньше OPTIONS-запросов, но изменения CORS могут ощущаться с опозданием из-за кэширования браузером. Это значение следует тщательно выбирать для критических API.

Область path

Политика CORS может быть привязана к конкретным условиям path или host. Это позволяет применять разное поведение CORS к разным поверхностям API в рамках одного vService. Admin-эндпоинты и публичные эндпоинты не обязаны иметь одинаковые разрешения.

Запись аудита

Изменения политики CORS могут отслеживаться в рамках централизованной конфигурации и процесса аудита. Изменения в списке Origin или поведении credentials следует считать значимыми для безопасности. История изменений имеет ценность для отката и compliance.

Когда это использовать

Устранение ошибок CORS frontend API без изменений кода приложения

Когда приложение frontend обращается к API на другом домене, браузер может получить ошибку CORS. Добавление правильной политики Origin, метода и заголовка через TR7 решает проблему централизованно.

Политика origin на основе regex для структур с несколькими субдоменами тенантов

В SaaS-среде каждый тенант может запускать собственный frontend на выделенном субдомене. Allow-list с поддержкой regex принимает всё дерево доменов тенантов контролируемым образом.

Узкий список origin и заголовков для доступа partner API

Партнёрские приложения могут обращаться к API только с конкретными Origin и заголовками Authorization. Правило CORS TR7 определяет эти разрешения централизованно и закрывает ненужную поверхность заголовков и методов.

Управление поведением credentials в SSO-потоках на основе cookie

В SSO или федеративных потоках могут потребоваться cross-origin cookie. TR7 берёт это поведение под контроль с переключателем credentials и узким списком Origin.

Применение разного поведения CORS к публичным и admin API путям

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

Часто задаваемые вопросы

Как правило CORS TR7 управляет preflight-запросами?

TR7 может генерировать необходимые заголовки Access-Control-Allow-Methods, Access-Control-Allow-Headers и Access-Control-Max-Age для OPTIONS preflight-запросов из центральной политики CORS. Это означает, что бэкенд-сервис не обременяется preflight-накладными расходами — он фокусируется только на реальном API-запросе.

Обязывает ли Origin allow-list использовать wildcards?

Нет. Политика CORS TR7 поддерживает определение разрешённых значений Origin через явный список или правила regex. Доверенным источникам frontend может быть предоставлен доступ без необходимости использовать wildcards, обеспечивая совместимость с браузером без излишнего раскрытия поверхности API.

Безопасно ли включать поведение credentials?

Когда credentials активны, cookie и заголовки Authorization могут использоваться в cross-origin запросах. В этом режиме критично, чтобы Origin allow-list был узким и чётко определённым; использование wildcard Origin вместе с credentials — небезопасная конфигурация. TR7 управляет обеими настройками вместе в единой центральной точке политики.

Можно ли применять разные политики CORS к разным API на одном устройстве?

Да. Политика CORS может быть определена независимо на уровне vService или path. Публичные API, partner API, admin API и internal API могут работать на одном устройстве с разными списками Origin, разными разрешениями методов и разным поведением credentials.

Каким должно быть значение Max-Age?

Подходящее Max-Age снижает OPTIONS-трафик для частых API-вызовов, но слишком длинное значение может привести к тому, что изменения политики CORS отразятся с опозданием из-за кэширования браузером. Для критических или часто обновляемых API предпочтительнее короткое значение. TR7 делает этот параметр настраиваемым под потребности каждого сервиса.

Привязана ли политика CORS к фреймворку приложения?

Нет. TR7 CORS Policy Rule работает на уровне ADC и не зависит от языка или фреймворка приложения. Все API, включая legacy-сервисы, могут публиковаться под одной центральной политикой CORS. Команды приложений достигают соответствия CORS без изменений настроек фреймворка.

Уберите управление CORS из кода приложения

Управляйте preflight, заголовками ответа, origin allow-list и поведением credentials из единого правила ADC. Давайте разберём живую настройку на ваших собственных сервисах.