Небезопасная настройка CORS: опасность Access-Control-Allow-Origin: *
Политика CORS регулирует доступ скриптов с одного домена к ресурсам другого домена.
Установка Access-Control-Allow-Origin: * в сочетании с передачей учетных данных (Credentials: true) позволяет сторонним вредоносным сайтам считывать приватные данные пользователей через их браузер.
Степень критичности и чем опасна уязвимость
Утечка пользовательских сессий и персональных данных при переходе пользователя на фишинговый сайт.
Как наш сканер находит эту уязвимость
Site Check отправляет запрос с произвольным заголовком Origin и проверяет, зеркалирует ли сервер этот Origin с подтверждением учетных данных.
Диагностика сетевых заголовков и серверных политик выполняется сбором и парсингом HTTP response headers на корневом и вспомогательных путях. Оценивается присутствие политик Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, а также атрибутов безопасности куки-файлов (HttpOnly, Secure, SameSite).
Как устранить уязвимость (Пошаговое руководство)
Для ликвидации риска выполните следующие действия в конфигурации вашего сервера или приложения:
# Разрешайте CORS только явно доверенным доменам:
if ($http_origin ~* (https?://(your-app\.com|admin\.your-app\.com)$)) {
add_header Access-Control-Allow-Origin "$http_origin";
}
- Никогда не используйте wildcard (*) для эндпоинтов, требующих авторизации.
- Проверяйте входящий Origin по строгому белому списку доменов компании.
Анатомия атаки и реальные последствия для проекта
Заголовок Access-Control-Allow-Origin: * в сочетании с Access-Control-Allow-Credentials: true позволяет любому стороннему сайту отправить асинхронный запрос от имени авторизованного пользователя и прочитать конфиденциальный ответ API.
Влияние на соответствие стандартам: Нарушение требований безопасности стандартов OWASP Top 10 (A05:2021 Security Misconfiguration), ISO/IEC 27001 и отраслевых норм 152-ФЗ.
Матрица эшелонированной защиты (Defense-in-Depth)
| Уровень защиты | Техническое действие | Инструмент / Механизм |
|---|---|---|
| Периметр веб-сервера (Nginx / Edge) | Применение изолирующих правил блокировки для маршрутов, связанных с cors-misconfiguration | Nginx Security Directives |
| Среда исполнения и конфигурация | Отключение отладочных механизмов и разграничение прав доступа к компоненту cors-misconfiguration | Runtime Security Hardening |
| Пайплайн DevSecOps контроля | Автоматическое тестирование конфигурации cors-misconfiguration в CI/CD пайплайне при каждом релизе | Site Check Security Gate |
Верификация устранения: команды для быстрой проверки
После внесения изменений в настройки сервера или исходный код приложения проверьте отсутствие уязвимости с помощью терминальных утилит:
curl -I -s -H "Origin: https://evil.com" https://ваш-домен.com/api/user | grep "Access-Control-Allow-Origin"
# Не должен возвращать * или origin атакующего
Рекомендации DevSecOps для безопасного развертывания
Никогда не отражайте заголовок Origin вслепую. Настройте строгий белый список доверенных доменов для CORS.
- ✓ Внедрить строгую политику Content-Security-Policy без небезопасных инлайн-скриптов
- ✓ Включить заголовок HSTS с директивой includeSubDomains и сроком не менее 1 года
- ✓ Установить флаги Secure, HttpOnly и SameSite=Lax для всех авторизационных куки
- ✓ Настроить редирект HTTP на HTTPS с корректным статус-кодом 301 Permanent
Часто задаваемые вопросы по устранению
Корректно настроенные заголовки безопасности формируют первый эшелон браузерной защиты клиентов. Отсутствие современных директив CSP и HSTS оставляет пользователей беззащитными перед атаками типа Clickjacking, MIME-sniffing и перехватом трафика в небезопасных сетях Wi-Fi.
Для предотвращения вектора «Небезопасная настройка CORS: опасность Access-Control-Allow-Origin: *» зафиксируйте проверочные правила в CI/CD пайплайне и настройте непрерывный мониторинг внешнего периметра через Site Check.