HttpOnly флаг

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

История

HttpOnly флаг был впервые предложен компанией Microsoft в 2002 году как расширение для Internet Explorer 6 Service Pack 1. Инициатива возникла как ответ на рост числа XSS-атак, направленных на кражу сессионных cookie. В 2004 году флаг был стандартизирован в черновике RFC 2965, а затем закреплён в спецификации RFC 6265 (2011 год), которая является действующим стандартом для HTTP cookies.

Первоначально поддержка HttpOnly флага была реализована только в Internet Explorer. Впоследствии его начали поддерживать все основные браузеры: Mozilla Firefox (с версии 2.0.0.5, 2007 год), Google Chrome (с первой версии, 2008 год), Apple Safari (с версии 3.0, 2007 год), Opera (с версии 9.5, 2008 год). На 2025 год поддержка HttpOnly флага является обязательной для всех современных браузеров.

Принцип работы

При установке cookie сервер может добавить в заголовок Set-Cookie атрибут HttpOnly. Пример:

`` Set-Cookie: sessionid=abc123; HttpOnly; Secure ``

Когда браузер получает такой cookie, он сохраняет его, но запрещает доступ к его значению через свойства document.cookie в JavaScript. Это означает, что даже если злоумышленник внедрит вредоносный скрипт на страницу (например, через XSS-уязвимость), он не сможет прочитать значение cookie, помеченного как HttpOnly.

Однако важно понимать, что HttpOnly флаг не защищает cookie от перехвата при передаче по сети — для этого используется флаг Secure (передача только по HTTPS) и шифрование. Также флаг не предотвращает подделку запросов (CSRF-атаки), для чего применяются другие механизмы (например, CSRF-токены).

Применение

HttpOnly флаг используется для защиты следующих типов cookie:

• Сессионные cookie — идентификаторы сессий пользователей. Это наиболее критичный случай, так как кража сессионного cookie позволяет злоумышленнику получить доступ к учётной записи жертвы.
• Cookie аутентификации — токены доступа (access tokens, refresh tokens), если они хранятся в cookie.
• Cookie с персональными данными — например, идентификаторы пользователей, предпочтения, настройки.

Рекомендуется устанавливать HttpOnly флаг для всех cookie, которые не требуют доступа из JavaScript. Если cookie используется только на стороне сервера (например, для поддержания сессии), он должен быть помечен как HttpOnly.

Ограничения

HttpOnly флаг не является панацеей и имеет ряд ограничений:

• Не защищает от XSS-атак — только от кражи cookie через них. Сама XSS-уязвимость остаётся, и злоумышленник может выполнять другие действия (например, изменять содержимое страницы, отправлять запросы от имени пользователя).
• Не защищает от перехвата трафика — требуется использование HTTPS и флага Secure.
• Не защищает от атак на уровне браузера — например, от вредоносных расширений или уязвимостей самого браузера.
• Не защищает от CSRF-атак — для этого нужны отдельные механизмы (CSRF-токены, SameSite флаг).
• Не защищает от атак, использующих другие методы хранения данных — например, localStorage или sessionStorage, если злоумышленник может их читать.

Рекомендации по использованию

Для обеспечения безопасности веб-приложений рекомендуется:

1. Устанавливать HttpOnly флаг для всех cookie, которые не требуют доступа из JavaScript.
2. Комбинировать HttpOnly с флагом Secure (передача только по HTTPS) и атрибутом SameSite (ограничение отправки cookie при кросс-доменных запросах).
3. Использовать механизмы Content Security Policy (CSP) для снижения риска XSS-атак.
4. Регулярно проводить аудит cookie на предмет необходимости доступа из JavaScript.
5. В случае необходимости доступа к cookie из JavaScript (например, для аналитики) — минимизировать объём хранимых данных и использовать отдельные cookie без HttpOnly.

Примеры реализации

На стороне сервера (Node.js с Express)

``javascript res.cookie('sessionid', 'abc123', { httpOnly: true, secure: true, sameSite: 'strict' }); ``

На стороне сервера (PHP)

``php setcookie('sessionid', 'abc123', [ 'httponly' => true, 'secure' => true, 'samesite' => 'Strict' ]); ``

На стороне сервера (Python с Flask)

``python response.set_cookie('sessionid', 'abc123', httponly=True, secure=True, samesite='Strict') ``

Критика

Основная критика HttpOnly флага связана с тем, что он не решает проблему XSS-атак, а лишь маскирует один из симптомов. Некоторые эксперты считают, что разработчики могут полагаться на HttpOnly как на единственную меру защиты, пренебрегая более фундаментальными методами предотвращения XSS (валидация входных данных, экранирование вывода, CSP).

Кроме того, HttpOnly флаг может создавать неудобства для разработчиков, которые хотят использовать JavaScript для управления сессиями (например, для реализации Single Page Applications). В таких случаях приходится искать альтернативные подходы (например, хранение токенов в памяти или использование Web Workers).

Интересные факты

• HttpOnly флаг не является обязательным по стандарту HTTP, но его использование настоятельно рекомендуется всеми крупными организациями по безопасности (OWASP, Google, Mozilla).
• В некоторых браузерах (например, Internet Explorer) HttpOnly флаг также блокирует доступ к cookie из скриптов, выполняемых в XMLHttpRequest, что может влиять на работу AJAX-приложений.
• Флаг не защищает от атак, использующих уязвимости в самом браузере (например, CVE-2019-11358 — уязвимость в jQuery, позволяющая читать HttpOnly cookie через DOM-манипуляции).

Источники

• RFC 6265 — HTTP State Management Mechanism
• OWASP — HttpOnly Flag
• Microsoft Developer Network — Mitigating Cross-site Scripting With HTTP-only Cookies
• Mozilla Developer Network — Set-Cookie
• Google Developers — SameSite cookies explained