Флаг куки Secure.

Атрибут Secure в заголовке Set-Cookie ограничивает куку зашифрованными соединениями: браузер никогда не передаст её по обычному HTTP, закрывая классический путь перехвата, при котором атакующий «на пути» (on-path) перехватывает сессионную куку или вынуждает жертву обратиться к http://-подресурсу, чтобы её утечь. Исторически это делало возможным «сайдджекинг» (sidejacking) — в 2010 году расширение Firefox Firesheep тривиально угоняло сессии Facebook и Twitter в открытом Wi-Fi именно потому, что тем кукам не хватало Secure, что подтолкнуло индустрию к полностью HTTPS-сайтам.

Одного Secure недостаточно: атакующий, способный внедриться по HTTP, всё ещё может перезаписать защищённую куку (атака «cookie tossing» / фиксации). Поэтому RFC 6265bis определяет два усиливающих префикса. Кука с именем __Secure-* обязана нести Secure и устанавливаться с HTTPS-источника; кука __Host-* дополнительно обязана опускать Domain и задавать Path=/, привязывая её к точному хосту и блокируя внедрение через поддомены. Браузеры молча отклоняют любую префиксную куку, нарушающую эти правила. Сочетайте Secure с HttpOnly, SameSite, узким scope и общесайтовым HSTS. Учтите, что исследование PortSwigger 2025 года «Cookie Chaos» показало, что причуды парсеров всё ещё могут обходить проверку префиксов в некоторых стеках — эшелонированная защита остаётся обязательной.

flowchart TD
  A[Сервер устанавливает куку] --> B{Атрибут Secure?}
  B -->|Нет| C[Отправляется по HTTP + HTTPS<br/>перехватываема в сети]
  B -->|Да| D{Схема запроса?}
  D -->|https://| E[Кука отправляется]
  D -->|http://| F[Кука не отправляется]
  E --> G{Префикс имени?}
  G -->|__Host-| H[Требует Secure, без Domain,<br/>Path=/ — привязана к хосту]
  G -->|__Secure-| I[Требует Secure +<br/>HTTPS-источник]
  G -->|нет| J[Перезаписываема через<br/>HTTP-внедрение]