HTTPOnly и Secure cookies

HTTPOnly и Secure cookies — это ревизия и настройка атрибутов cookies: ставим HTTPOnly (cookie недоступна из JavaScript — снижает кражу сессии при XSS), Secure (cookie передаётся только по HTTPS — не утечёт по http), проверяем срок жизни и область действия (path/domain). Честно про область, это важно: флаги защищают САМИ cookies (их кражу/передачу), но НЕ устраняют причину — уязвимость XSS в коде (её закрывает 752): если злоумышленник может выполнить скрипт, он навредит и без доступа к cookie. То есть это снижение последствий, а не замена защиты от XSS. Честно про предпосылку: Secure имеет смысл только при работающем HTTPS (736) — иначе cookie с Secure просто не будет ставиться. Честно про эффект: меньше риск кражи сессии, рост продаж сам по себе НЕ гарантируем. Честно про совместимость: если какой-то фронтенд-скрипт читал cookie напрямую — после HTTPOnly он этого делать не сможет (проверим и переделаем правильно). Честно про доступ: нужен доступ к коду/конфигу, где ставятся cookies. Важная граница: это флаги HTTPOnly/Secure, защита от CSRF через Same-Site — отдельная услуга (759), а защита от самого XSS — 752. Представьте: вместо «сессионную cookie можно украсть скриптом или перехватить по http» — cookie закрыта от JS и ходит только по HTTPS. Базовая цена — от 9 000 ₽ за проект.

• Сессионную cookie можно прочитать JavaScript'ом (кража сессии при XSS).
• Cookie передаётся по http и может быть перехвачена.
• Атрибуты cookies (срок, область) настроены небрежно.
• Чувствительные данные хранятся в cookie без защиты.

• Аудит текущих cookies и их атрибутов
• Установка флага HTTPOnly для сессионных/чувствительных cookies
• Установка флага Secure (только HTTPS)
• Ревизия срока жизни и области (path/domain)
• Проверка, что фронтенд не сломался (если читал cookie)
• Указание границ (не замена защиты от XSS)
• Проверка применения
• Передача и разбор с вами

• Сессионные cookies недоступны для JavaScript
• Cookies передаются только по HTTPS
• Меньше риск кражи/перехвата сессии
• Узкий, но важный слой (защита от XSS — отдельно)

• Снимаем все cookies и атрибуты, ищем читаемые фронтендом; собираем доступ
• Ставим HTTPOnly/Secure, ревизуем атрибуты, чиним совместимость
• Проверяем применение, разбираем границы с вами

• HTTPOnly защитит от XSS?

  Не от самого XSS, а от одного из последствий: с HTTPOnly украденный скрипт не сможет прочитать сессионную cookie. Но причина — уязвимость XSS в коде — остаётся, и её нужно закрывать отдельно (752): при XSS злоумышленник может навредить и без доступа к cookie. Это снижение последствий, а не замена защиты.

• Secure точно нужен?

  Да, если у вас HTTPS (а он должен быть). Secure запрещает передачу cookie по незащищённому http — иначе её можно перехватить. Важно: Secure имеет смысл только при работающем HTTPS; если его нет — сначала TLS (736).

• Не сломается ли что-то на сайте?

  Может, если какой-то фронтенд-скрипт читал cookie напрямую — после HTTPOnly он этого не сможет. Поэтому сначала аудит: найдём такие места и переделаем правильно (через сервер), чтобы ничего не отвалилось.