Как защитить сессионные куки боевого сервера от утечки через уязвимости на тестовых стендах?

Разработчики часто разворачивают dev- и staging-окружения на путях вроде example.com/dev, используя общие куки с флагом Domain=.example.com. В таком сценарии XSS-атака или взлом слабо защищенного dev-стенда позволяет хакеру мгновенно перехватить сессию администратора от основного prod-сервера.

Разделение окружений на изолированные поддомены полностью блокирует этот вектор на уровне браузера.

Пример уязвимой конфигурации, при которой куки улетают на все поддомены и окружения:

$ # НЕПРАВИЛЬНО: кука доступна для dev.example.com и prod.example.com
$ Set-Cookie: session=secret; Domain=.example.com; Path=/

Правильная изоляция сессии, при которой браузер отдаст куку только конкретному хосту:

$ # ПРАВИЛЬНО: жесткая привязка сессии к боевому домену
$ Set-Cookie: session=secret; Domain=prod.example.com; Path=/; SameSite=Strict

🔥 Важно: если вы опустите атрибут Domain вовсе, браузер по умолчанию привяжет куку строго к текущему хосту (Host-only cookie), что является самой безопасной практикой.

➡️ Hacking Ready | #совет