Глоссарий
Что такое CORS — как он работает и что открывает неправильная настройка
CORS управляет тем, может ли JavaScript одного сайта читать ответы API другого источника. Неправильная настройка CORS позволяет стороннему сайту читать данные вошедшего пользователя. Безопасно: allowlist, не отражать Origin, не смешивать * и куки.
«Я добавил Access-Control-Allow-Origin, и API заработал — это безопасно?» CORS — это не «добавил и готово»; суть в том, чтобы сузить, кому вы разрешаете. Разберём, как он работает и как настроить его безопасно (без шагов атаки).
Сначала о том, как это работает
Браузеры применяют политику одного источника: JS другого источника не может свободно читать ответы другого сайта. CORS существует, чтобы открыть это исключение только тем, кому сервер явно разрешает.
| Заголовок ответа | Значение |
|---|---|
Access-Control-Allow-Origin | Каким источникам можно читать ответ |
Access-Control-Allow-Credentials | Разрешены ли запросы с учётными данными (куками) |
Access-Control-Allow-Methods / -Headers | Какие HTTP-методы/заголовки разрешены |
Суть: CORS находится на стороне «ослабления ограничения». Ослабьте его неверно — и данные, которые не должны быть читаемы, становятся читаемыми для третьих сторон.
Что делает настройку опасной
Опасные настройки (частые)
- Отражение Origin запроса обратно как разрешённого
Access-Control-Allow-Origin: *плюс разрешение учётных данных- Открытие API широко кросс-доменно, когда это не нужно
Безопасные настройки
- Allowlist (только фиксированные доверенные источники)
- Запрет по умолчанию для всего остального
- Для запросов с учётными данными — конкретный источник, а не
*
Основы безопасной настройки
Используйте allowlist (самое важное)
Не отражайте Origin вслепую
Origin запроса прямиком в Access-Control-Allow-Origin. Возвращайте его только когда он совпадает с allowlist.Никогда не используйте * с учётными данными
Access-Control-Allow-Origin: * с Allow-Credentials: true. Вместо этого указывайте конкретный источник.Минимизируйте то, что открываете
Мнение этого сайта: CORS — это «как ослабляешь», а не «защита» — сужайте, кому открываете
Частое заблуждение — «добавление заголовков CORS делает безопасно». Всё наоборот — CORS ослабляет ограничение браузера. Поэтому хитрость не в том, «как добавить», а в том, чтобы «минимизировать, кому и насколько широко открываешь.» На этом сайте мы отделяем данные, которые можно читать извне, от тех, которые нельзя, и рекомендуем запрет по умолчанию с allowlist, открывающим только исключения. Заметьте, что XSS (который ломает предпосылку о чтении) и CSRF (который нацелен на изменения состояния) — это отдельные уязвимости: один лишь CORS не покрывает всё.
Читать дальше
- Глоссарий: Что такое XSS · Что такое CSRF
- Проверка: Проверщик заголовков безопасности
FAQ
QДля чего нужен CORS?
Браузеры применяют политику одного источника: JavaScript одного источника (сайта) не может свободно читать ответы другого сайта. CORS (Cross-Origin Resource Sharing) — это то, как сервер открывает исключение из этого правила, но только тем, кому явно разрешает. Заголовки ответа вроде Access-Control-Allow-Origin объявляют, каким источникам можно читать ответ.
QЧто открывает неправильная настройка CORS?
Слишком слабые разрешения могут позволить сайту злоумышленника читать через JavaScript ответы API пользователя с активным сеансом. Классические случаи: отражение Origin запроса обратно как разрешённого или установка Access-Control-Allow-Origin в * при одновременном разрешении учётных данных (кук). В результате персональные данные или токены могут попасть на сторонний сайт.
QЧто лежит в основе безопасной настройки?
Allowlist. Разрешайте только заранее определённые доверенные источники, а остальное запрещайте (запрет по умолчанию). Не отражайте Origin запроса вслепую. Для запросов с учётными данными не используйте * в Access-Control-Allow-Origin — указывайте конкретный источник. И открывайте кросс-доменно только те эндпоинты, которым это действительно нужно.