Как параметры куки влияют на безопасность

Что проверяют

Понимаете ли вы, от какой атаки защищает каждый атрибут и чего он не делает. Типичное уточнение: «Где хранить токен сессии, в куке или в localStorage, и почему?»

Как отвечать

Пройдитесь по атрибутам и привяжите каждый к угрозе:

• HttpOnly: кука недоступна из document.cookie. При XSS её не унесут на чужой сервер, но сама XSS никуда не девается: скрипт злоумышленника по-прежнему шлёт запросы от имени пользователя, и браузер приложит куку сам;
• Secure: кука уходит только по HTTPS, перехват в открытой сети не сработает. Для localhost браузеры делают исключение, чтобы работала локальная разработка;
• SameSite: главный инструмент против CSRF. Strict не отправляет куку при переходе с чужого сайта, Lax отправляет только при навигации верхнего уровня безопасным методом вроде GET, None отправляет всегда и требует Secure. Без атрибута Chrome ведёт себя как при Lax;
• Domain: без него кука привязана к точному хосту. Указали Domain=example.com, и кука уходит на все поддомены, включая сторонние сервисы на них;
• Path: удобство, а не граница безопасности. Страница того же источника доберётся до куки другого пути, например через iframe;
• Expires и Max-Age: чем дольше живёт кука сессии, тем дольше работает украденная;
• префиксы __Host- и __Secure-: куку __Host- браузер примет только с Secure, Path=/ и без Domain, так её не перезапишет поддомен.

Итог для сессии: __Host-session=...; Secure; HttpOnly; SameSite=Lax; Path=/, плюс CSRF-токен для критичных действий.

Где спотыкаются

Говорят, что HttpOnly защищает от XSS. Он лишь снижает ущерб, а защищают экранирование вывода и Content Security Policy.

Путают site и origin. SameSite считает одним сайтом все поддомены одного регистрируемого домена, поэтому запрос с evil.example.com на app.example.com он не отсекает.

Меняют состояние через GET. При Lax кука уходит при переходе по ссылке с чужого сайта, и GET /delete?id=1 становится уязвимым.