Gernar
Браузер, DOM и Web API

Как разрешить клиенту выходить в другой домен

Разбор вопроса «Как разрешить клиенту выходить в другой домен» для Frontend Developer: что проверяет интервьюер, ключевые тезисы, практические примеры и частые ошибки.

Вопрос

Как разрешить клиенту выходить в другой домен

Профессия

Frontend Developer

Что хочет услышать интервьюер

Интервьюер хочет убедиться, что кандидат понимает механизмы междоменных запросов, знает современные (CORS) и устаревшие (JSONP) методы, а также может объяснить настройку сервера и клиента для безопасного взаимодействия.

Ключевые тезисы

  • Использовать CORS (Cross-Origin Resource Sharing) — механизм, позволяющий браузеру запрашивать ресурсы с другого домена. Для этого сервер должен включать заголовки Access-Control-Allow-Origin и другие CORS-заголовки.
  • Настроить сервер для обработки предварительных запросов (preflight requests) с помощью метода OPTIONS, если запросы содержат нестандартные заголовки или методы.
  • Для JSONP (устаревший метод) — использовать динамическое создание тега <script>, но он не поддерживает POST-запросы и менее безопасен.
  • При работе с прокси-сервером (например, в dev-среде) — настроить проксирование запросов через конфигурацию веб-сервера (Nginx, Apache) или инструментов вроде webpack-dev-server.

Подробный ответ

Для разрешения клиенту выходить в другой домен чаще всего используется механизм CORS (Cross-Origin Resource Sharing). CORS — это стандарт, который позволяет серверу явно указать, какие домены могут запрашивать его ресурсы. Без CORS браузер по соображениям безопасности блокирует кросс-доменные запросы. Сервер должен включать заголовки, такие как Access-Control-Allow-Origin, чтобы разрешить доступ. Например, Access-Control-Allow-Origin: * разрешает доступ всем доменам, но для безопасности лучше указывать конкретные домены.

Кросс-доменные запросы делятся на простые (simple) и сложные (complex). Простые запросы используют методы GET, POST или HEAD и не содержат нестандартных заголовков. Сложные запросы требуют предварительного (preflight) запроса методом OPTIONS, чтобы проверить, разрешён ли основной запрос. Сервер должен корректно обрабатывать OPTIONS-запросы, возвращая соответствующие CORS-заголовки.

Альтернативой CORS является JSONP, который использует тег <script> для загрузки данных. Однако JSONP устарел, не поддерживает POST-запросы и менее безопасен. Другой вариант — настройка прокси-сервера, который перенаправляет запросы клиента на целевой домен, избегая ограничений CORS. Это часто используется в development-среде с помощью инструментов вроде webpack-dev-server.

Безопасность CORS критически важна. Не следует использовать Access-Control-Allow-Origin: * в продакшене, если нет необходимости. Лучше явно указывать доверенные домены. Также можно использовать Access-Control-Allow-Credentials: true для запросов с учётными данными (куки, заголовки авторизации), но это требует дополнительных проверок.

Практические примеры

Пример 1

Пример настройки CORS в Express.js с ограничением по домену и обработкой preflight-запросов.

Пример 2

Пример конфигурации Nginx для разрешения кросс-доменных запросов с определённого домена.

Пример 3

Использование прокси в webpack-dev-server для обхода CORS в development-среде.

Частые ошибки

  • Использование Access-Control-Allow-Origin: * в продакшене без необходимости, что может привести к уязвимостям.
  • Неверная обработка preflight-запросов (OPTIONS), из-за чего сложные запросы блокируются.
  • Отсутствие заголовка Access-Control-Allow-Credentials при работе с запросами, требующими учётных данных.

Связанные темы

  • Same-Origin Policy (Политика одинакового источника)
  • HTTP-заголовки безопасности (Content-Security-Policy, X-Frame-Options)
  • JWT (JSON Web Tokens) для авторизации в кросс-доменных запросах
  • Настройка прокси-серверов (Nginx, Apache, Cloudflare)

Follow-up вопросы

Какие заголовки CORS обязательно должны быть на сервере для разрешения кросс-доменных запросов?

Уровень: basic

Основные заголовки: Access-Control-Allow-Origin (указывает разрешенные домены), Access-Control-Allow-Methods (разрешенные HTTP-методы), Access-Control-Allow-Headers (разрешенные заголовки запроса). Для preflight-запросов также важен Access-Control-Max-Age.

Как обрабатывать preflight-запросы (OPTIONS) на сервере?

Уровень: intermediate

Сервер должен обрабатывать OPTIONS-запросы, возвращая корректные CORS-заголовки без выполнения основной логики. Например, в Express.js можно использовать middleware для автоматической обработки таких запросов.

В чем разница между простыми (simple) и сложными (complex) CORS-запросами?

Уровень: intermediate

Простые запросы используют методы GET, POST или HEAD и имеют ограниченный набор заголовков. Сложные запросы — все остальные (например, с кастомными заголовками). Для сложных запросов браузер сначала отправляет preflight (OPTIONS).

Как обеспечить безопасность при настройке CORS, чтобы не открывать доступ всем доменам?

Уровень: advanced

Не использовать Access-Control-Allow-Origin: * для конфиденциальных данных. Вместо этого явно указывать доверенные домены, валидировать их на сервере и, по возможности, использовать whitelist. Для защиты от CSRF добавлять проверку Origin/Referer.

Какие альтернативы CORS существуют для кросс-доменных запросов?

Уровень: intermediate

JSONP (только GET, устарел), прокси-сервер (запросы идут через свой бэкенд), WebSockets или Server-Sent Events (SSE). Для локальной разработки — настройка прокси в webpack/dev-сервере.

Содержание