Flag de cookie Secure.

O atributo Secure num cabeçalho Set-Cookie restringe um cookie a conexões cifradas: o navegador nunca o transmitirá por HTTP simples, fechando o caminho de interceção clássico em que um atacante on-path fareja um cookie de sessão ou força a vítima a um sub-recurso http:// para o vazar. Historicamente, isto permitiu o "sidejacking" — a extensão de Firefox Firesheep, de 2010, sequestrava trivialmente sessões do Facebook e do Twitter em Wi-Fi aberto precisamente porque esses cookies não tinham Secure, o que empurrou a indústria para HTTPS em todo o site.

Secure por si só não é suficiente: um atacante capaz de injetar sobre HTTP pode ainda sobrescrever um cookie seguro (um ataque de "cookie tossing" / fixação). Por isso, o RFC 6265bis define dois prefixos de endurecimento. Um cookie com o nome __Secure-* tem de incluir Secure e ser definido a partir de uma origem HTTPS; um cookie __Host-* tem adicionalmente de omitir Domain e definir Path=/, fixando-o ao host exato e bloqueando a injeção baseada em subdomínios. Os navegadores rejeitam silenciosamente qualquer cookie com prefixo que viole estas regras. Combine Secure com HttpOnly, SameSite, escopo restrito e HSTS em todo o site. Note que a investigação "Cookie Chaos" de 2025 da PortSwigger mostrou que peculiaridades de parsing ainda podem contornar a imposição de prefixos em algumas stacks — a defesa em profundidade continua a ser essencial.

flowchart TD
  A[Servidor define cookie] --> B{Atributo Secure?}
  B -->|Não| C[Enviado por HTTP + HTTPS<br/>fareijável na rede]
  B -->|Sim| D{Esquema do pedido?}
  D -->|https://| E[Cookie enviado]
  D -->|http://| F[Cookie retido]
  E --> G{Prefixo do nome?}
  G -->|__Host-| H[Exige Secure, sem Domain,<br/>Path=/ - fixado ao host]
  G -->|__Secure-| I[Exige Secure +<br/>origem HTTPS]
  G -->|nenhum| J[Sobrescrevível via<br/>injeção HTTP]