Как разрешить клиенту выходить в другой домен
Разбор вопроса «Как разрешить клиенту выходить в другой домен» для 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-сервере.
Как применял полифилы на практике
Разбор вопроса «Как применял полифилы на практике» для Frontend Developer: что проверяет интервьюер, ключевые тезисы, практические примеры и частые ошибки.
Как синхронизировать разные вкладки
Разбор вопроса «Как синхронизировать разные вкладки» для Frontend Developer: что проверяет интервьюер, ключевые тезисы, практические примеры и частые ошибки.