Почему мультидомен сейчас везде и при чем тут безопасность
Когда бизнес вырастает из одного лендинга, внезапно выясняется: проект живет сразу на нескольких доменах. Отдельный домен под блог, другой под личный кабинет, третий под админку или мобильное API, иногда — под партнерские интеграции. На уровне маркетинга это удобно, а на уровне безопасности и веб-стандартов начинается настоящий квест: «как все связать, не превращая систему в проходной двор».
В этот момент всплывает тема веб стандарты безопасности для мультидоменных систем. Игнорировать их уже не получается: браузеры стали жестче, регуляторы — требовательнее, а любые дыры в мультидоменной архитектуре масштабируются в разы быстрее, чем в монолите на одном домене. Цель статьи — разобрать практику: что реально работает, где люди стабильно ошибаются и какие есть нестандартные, но эффективные решения, которые обычно вспоминают только в командах с сильной безопасностью.
Базовая картина: как браузер смотрит на несколько доменов
Контекст безопасности и политика происхождения
Главный герой мультидоменной интеграции — Same-Origin Policy (SOP). Браузер считает «одинаковым происхождением» только связку: схема (https), домен (example.com) и порт (443). Все, что отличается хотя бы в одном параметре, — уже другой origin.
Когда у вас идет интеграция нескольких доменов в один сайт безопасность сразу усложняется, потому что:
— `app.example.com` и `auth.example.com` — это разные origin, хотя домен вроде бы общий;
— `example.com` и `example.org` — вообще «чужие люди»;
— перенос части фронта на CDN с отдельным доменом еще больше дробит контекст.
SOP по умолчанию блокирует прямой доступ к данным между такими источниками, и это хорошо: меньше поверхность атаки. Но для реального приложения часто нужно, чтобы домены взаимодействовали — шарили сессии, обменивались токенами, вызывали друг у друга API. Значит, приходится аккуратно ослаблять ограничения, не ломая общую модель защиты.
Кейс из практики: мультидоменный маркетинг и утечка токенов
Реальный пример. Маркетинговый портал на `marketing.company.com` подключили к основному личному кабинету на `lk.company.com`. Ребята добавили iframe с личным кабинетом, разрешили CORS на все поддомены и расслабились. Через пару месяцев обнаружили: токены авторизации «гуляют» в логах стороннего сервиса аналитики, который встраивался на маркетинговый домен через скрипт.
Причина проста: один из JS-скриптов мог читать параметры URL, в том числе токен, который прокидывали через redirect от `auth.company.com` к `marketing.company.com`, и случайно (или не случайно) отправлял его наружу. Тогда и вспомнили, что решения для безопасной мультидоменной интеграции веб приложений нужны не в виде «настройте CORS и живите счастливо», а в виде конкретной схемы обмена данными и очень строгих правил для каждой точки интеграции.
Ключевые веб-стандарты, без которых мультидомен лучше даже не начинать
CORS, но по-взрослому, а не `Access-Control-Allow-Origin: *`
Многие считают CORS чем-то вроде «галочки, которая разрешает фронту ходить на другой домен». В мультидоменной среде так делать нельзя. Грубый `*` — это почти приглашение для XSS-паразитов и прокладка пути для кражи токенов.
Для настройка безопасности при интеграции нескольких доменов стоит придерживаться практики:
— Явно перечислять доверенные origin, а не использовать `*`.
— Разделять список доменов по типу доступа: одни могут только GET, другие — POST/PUT.
— Запрещать отправку cookies там, где это не критично (через `credentials: include` и `Access-Control-Allow-Credentials`).
Нюанс, который часто пропускают: CORS — это *прослойка, а не основной замок*. Он не заменяет проверку прав на сервере. Бэкенд, который доверяет наличию заголовка CORS больше, чем своему ACL или токенам, — это типичный кандидат на инциденты.
Cookie-домены, флаги безопасности и разнесение ответственности
Когда нужно «общая авторизация на всех поддоменах», разработчики часто ставят cookie на `.example.com` и считают задачу решенной. На практике вы получаете:
— общий токен, доступный *любому* поддомену, включая тестовые и старые;
— возможность XSS на второстепенном домене перехватить cookie и увести весь аккаунт.
Гораздо безопаснее использовать:
— отдельный auth-домен (например, `auth.example.com`), который:
— ставит HttpOnly и Secure cookies только для себя;
— отдает фронту короткоживущие токены доступа (access token) и обновления (refresh token) через защищенные каналы.
— строгие флаги: `SameSite=Lax` или `SameSite=Strict` для максимума cookie; `None` — только там, где по-другому никак и только с HTTPS.
Такое разделение помогает реализовать более тонкие решения для безопасной мультидоменной интеграции веб приложений, а не жить одним «жирным» cookie на весь зоопарк доменов.
Неочевидные решения, о которых редко пишут в базовых гайдах
Построение доверенной шины через backend-for-frontend (BFF)
Когда доменов много, любой фронт, который сам разговаривает с десятком API, быстро утрачивает контроль: заголовки, токены, версии протоколов, нестабильные CORS-правила. Один из аккуратных и неочевидных подходов — backend-for-frontend.
Схема проста: вместо того, чтобы фронтенд на `app.example.com` стучался к `api.example.org`, `billing.partner.com` и `cdn.files.com`, он ходит только к своему BFF — скажем, `bff.app.example.com`. А уже BFF, как внутренний маршрутизатор, общается с другими доменами по заранее оговоренным правилам.
Плюсы:
— токены и секреты не покидают серверную зону;
— CORS-настройки становятся проще — фронт общается только с одним доменом;
— можно жестко фильтровать и нормализовать данные до выхода к реальному пользователю.
Для сложных мультидоменных схем такой BFF иногда превращается в ядро интеграционной архитектуры, а фронт почти не знает, что с той стороны несколько доменов, а не один.
Защита данных через message channel, а не через общий DOM
Когда используют iframe между доменами (например, виджет платежей, встроенный в основной сайт), многие боятся утечек и ломают себе логику, лишая фрейм возможности нормально работать. Вместо попытки «подружить» DOM между доменами, лучше полагаться на стандарт `postMessage` и MessageChannel.
Пара лайфхаков:
— Не полагайтесь только на `event.origin`, проверяйте еще ожидаемый `event.source`, чтобы убедиться, что сообщение пришло из нужного окна/фрейма.
— Определите строгий формат сообщений (тип, версия, payload), валидируйте его до любой логики.
— Используйте одноразовые «ключи сессии» между фреймами, чтобы атакующий не мог подгадать окно и подсунуть свои данные.
Такой подход превращает iframe-интеграцию из непредсказуемого хака в управляемый канал обмена сообщениями, который хорошо документируется и аудируется.
Альтернативные методы интеграции: когда что выбирать
Вариант 1: Одинаковый домен, разные пути
Самый безопасный, но не всегда удобный с маркетинговой точки зрения подход: держать все под одним основным доменом, меняя только путь:
— `example.com/app`
— `example.com/admin`
— `example.com/blog`
Плюсы:
— минимум проблем с CORS и cookie-доменами;
— предсказуемая политика безопасности (CSP, HSTS, заголовки).
Минусы:
— сложнее раздать зоны ответственности между командами;
— миграции и деплой иногда становятся комом, если нет грамотного разделения на уровне инфраструктуры.
Этот метод часто выбирают банки и крупные B2B-сервисы, где безопасность важнее маркетинговой гибкости.
Вариант 2: Отдельные домены с единым центром авторизации (SSO)
Классика: `company.com`, `cabinet.company.ru`, `partner-company.net` и независимый `auth.company.com`, который выдает токены всем. Пользователи видят разные домены, но входят один раз и дальше не замечают «раздробленности».
Чтобы интеграция нескольких доменов в один сайт безопасность не роняла, нужно:
— использовать протоколы вроде OAuth2/OpenID Connect с четкими ролями клиента и сервера;
— не передавать токены через фрагменты URL без строгой валидации;
— ограничивать срок жизни access-токена и при необходимости часто обновлять его по refresh-токену.
Такой подход хорошо ложится на мобильные клиенты, SPA и сторонние интеграции, если все токены проверяются централизованно.
Вариант 3: API-шлюз как точка входа и фильтра
Еще один альтернативный метод — не плодить прямые маршруты между доменами, а прокидывать все внешние вызовы через API-шлюз. Он:
— занимается аутентификацией и rate limiting;
— внедряет кросс-срезные политики безопасности;
— логирует весь трафик для последующего анализа.
API-шлюз особенно полезен, если вы хотите заказывать наружные услуги по аудиту безопасности мультидоменных веб проектов: аудиторам проще анализировать концентрированный поток запросов и политику доступа, чем выискивать случайные ручки, торчащие на каждом домене.
Реальные кейсы и типичные ошибки при мультидоменной интеграции
Кейс: тестовый домен как дырка в проде
Частая история: `test.example.com` или `dev.example.com` подключают к тем же auth-сервисам, что и боевой домен. Из хороших побуждений — чтобы «тестировать на настоящей авторизации». На тестовом домене слабее CSP, отключены некоторые проверки, часто есть отладочные эндпоинты. В итоге:
— токены, работающие в проде, можно украсть через XSS на тестовом домене;
— часть конфиденциальных API-доступов видна через открытый Swagger или незащищенный admin-интерфейс.
Устойчивое решение — создавать изолированные контуры авторизации для non-prod-доменов и принципиально не использовать боевые токены. Даже если это немного усложняет тестирование, цена ошибки на проде гораздо выше.
Кейс: единый CDN для статики и пользовательского контента
Другая типичная ловушка: CDN на `cdn.example.com` отдает и статический фронтенд, и пользовательские файлы (загрузки, аватары, документы). Если по ошибке включить одинаковую политику для всего домена CDN, пользователь может загрузить файл, который браузер интерпретирует как HTML/JS с теми же правами, что и основной фронтенд. Это почти бесплатный XSS.
Решение: жестко разделять пользовательский контент и статику эшелоном доменов:
— `static.example.com` — только проверенный код, строгие CSP;
— `files.example.com` — только вложения с `Content-Type: application/octet-stream` и запретом inline-отображения там, где возможно.
Это неочевидный шаг, который часто пропускают на старте, а потом приходится перестраивать структуру URL и кэш-политику.
Лайфхаки для профессионалов: куда копать глубже
Продвинутая настройка заголовков безопасности
Когда речь идет о нескольких доменах, заголовки становятся вашим лучшим другом. Профессионалы обычно уделяют внимание таким вещам:
— Content-Security-Policy (CSP) — не одна общая политика на все домены, а профильная для каждого:
— фронту — минимум доверенных источников скриптов, запрет inline-кода;
— доменам с пользовательским контентом — максимально ограниченный набор директив.
— Strict-Transport-Security (HSTS) — включаем для всех доменов, которые участвуют в авторизации или важном трафике, с добавлением в preload, если это допустимо для проекта.
— X-Frame-Options и/или CSP frame-ancestors — только конкретные домены имеют право встраивать ваши страницы в iframe, а не «все подряд».
В мультидоменной архитектуре эти заголовки становятся не просто защитой, а дополнительной декларацией доверенных связей между доменами.
Минимальный набор постоянных практик
Чтобы систему не «рвало» при каждом добавлении нового домена, полезно завести короткий чек-лист:
— какие домены могут устанавливать авторизационные cookies;
— какие домены могут инициировать авторизацию или логаут;
— какие домены имеют право встроить iframe с критичным функционалом;
— какие протоколы (OAuth2, SAML, OpenID Connect) используются и где именно.
С практической точки зрения этот список должен быть не просто документом, а основой для автоматизированных проверок: линтеров, CI-пайплайнов и периодических сканеров.
От чего зависят качественные услуги по аудиту безопасности
Когда приходит время заказывать услуги по аудиту безопасности мультидоменных веб проектов, эксперты в первую очередь смотрят не на «модные технологии», а на:
— прозрачность архитектуры доменов и субдоменов;
— консистентность политик безопасности между ними;
— отсутствие «диких» доменов, про которые забыли в документации;
— корректную эксплуатацию веб-стандартов: CORS, CSP, cookie-флагов, механизмов SSO.
Чем аккуратнее вы формализуете мультидоменную схему заранее, тем полезнее будет аудит: он покажет реальные слабые места, а не потратит время на реконструкцию архитектуры по кускам кода и логов.
Как подойти к мультидоменной архитектуре без хаоса
Мультидоменная интеграция — это не про «наклеить вместе десяток доменов» и радоваться единому дизайну. Это про аккуратное выстраивание доверенных связей, в которых каждый домен понимает свои роли и ограничения. Если опираться на продуманные веб-стандарты, а не на рандомные хаки, вы:
— снижаете шансы, что один скомпрометированный домен потянет за собой остальных;
— упрощаете разработку, потому что правила интеграции понятны и одинаковы для всех;
— облегчаете ввод новых доменов в экосистему, не усложняя логику до состояния «никто не понимает, как это работает».
Практический подход: начинайте с явной схемы доменов, пропишите для каждого задачи и уровень доверия, выберите подходящие стандарты (CORS, OAuth2/OIDC, CSP, безопасные cookies), а потом уже думайте, как это красивее упаковать в маркетинговые URL. Безопасность в мультидоменной архитектуре — не тормоз, а способ сохранять контроль, пока система растет.