Set-Cookie

Baseline Widely available *

This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.

* Some parts of this feature may have varying levels of support.

O cabeçalho de resposta HTTP Set-Cookie é usado para enviar cookies de um servidor para o agente usuário.

Para mais informações, veja o guia em HTTP cookies.

Header type Response header
Forbidden header name no

Sintaxe

Set-Cookie: <nome-cookie>=<valor-cookie>
Set-Cookie: <nome-cookie>=<valor-cookie>; Expires=<date>
Set-Cookie: <nome-cookie>=<valor-cookie>; Max-Age=<non-zero-digit>
Set-Cookie: <nome-cookie>=<valor-cookie>; Domain=<domain-value>
Set-Cookie: <nome-cookie>=<valor-cookie>; Path=<path-value>
Set-Cookie: <nome-cookie>=<valor-cookie>; Secure
Set-Cookie: <nome-cookie>=<valor-cookie>; HttpOnly

Set-Cookie: <nome-cookie>=<valor-cookie>; SameSite=Strict
Set-Cookie: <nome-cookie>=<valor-cookie>; SameSite=Lax

// São possíveis multiplas diretivas, por exemplo:
Set-Cookie: <nome-cookie>=<valor-cookie>; Domain=<domain-value>; Secure; HttpOnly

Diretivas

Um cookie começa com um par nome-valor:

  • Um <nome-cookie> pode ser qualquer caractere US-ASCII exeto caracteres de controle (CTLs), espaços, ou tabulações (TAB). Também não deve conter um separador de caractere como os seguintes: ( ) < > @ , ; : \ " / [ ] ? = { }.
  • Um <valor-cookie> pode opcionalmente ser atribuido entre aspas duplas e qualquer caractere US-ASCII são permitidos, exceto caracteres de controle (CTLs), espaços em branco, aspas duplas, vírgula, barra invertida e ponto e vírgula. Codificação: Muitas implementações realizam codificação URL nos valores de cookie, contudo não é obrigatório pela especificação do RFC. Isso ajuda a satisfazer os requisitos sobre quais caracteres são permitidos para <valor-cookie>.
  • Prefixo __Secure-: Cookies com o nome começando com __Secure- (hífen faz parte do prefixo) precisam ser atribuidos com a flag de segurança e precisam ser de uma página segura (HTTPS).
  • Prefixo __Host-: Cookies com o nome começando com __Host- (hífen faz parte do prefixoprecisam ser atribuidos com a flag de segurança, precisam ser de uma página segura (HTTPS), não precisam ter um domínio especificado (portanto não são enviados para subdomínios) e o caminho (path) precisa ser "/".
Expires=<data> Optional

O tempo de vida máximo do cookie como uma marcação de tempo (timestamp) HTTP. Veja Date para a formatação detalhada.

Se não especificado, o cookie terá o tempo de vida de uma sessão de cookie. Uma sessão é finalizada quando o cliente é desligado, significando que as sessões de cookies serão removidos nesse momento. Contudo, muitos navegadores web têm uma característica denominada de "restaurar sessão" que salvará todas suas abas e as trará de volta na próxima vez em que você utilizar o navegador. Os cookies estarão também presentes e será como se o navegador nunca tivesse sido fechado.

Quando uma data de expiração é atribuída, o tempo e a data são relativos ao cliente em que os cookies estão sendo configurados e não ao servidor.

Max-Age=<digito-diferente-de-0> Optional

Número de segundos até o cookie expirar. Um ou mais digitos de 1 a 9. Navegadores antigos (ie6, ie7 e ie8) não suportam Max-Age. Para cada navegador, se ambos (Expires e Max-Age) forem atribuídos, Max-Age terá precedência.

Domain=<valor-domínio> Optional

Especifica os hosts aos quais o cookie será enviado.

  • Se não for especificado, será usado o host do URL do documento atual, não incluindo subdomínios.
  • Ao contrário das especificações anteriores, pontos de prefixo em nomes de domínio (.example.com) são ignorados.
  • Se um domínio for especificado, subdomínios estarão sempre incluídos.
Path=<valor-caminho> Optional

Indica um caminho (path) de URL que necessita existir no recurso solicitado antes de enviar o cabeçalho de Cookie. O caractere %x2F ("/") é interpretado como um separador de diretório e os sub-diretórios serão também correspondidos (por exemplo: Path=/docs, "/docs", "/docs/Web", ou "/docs/Web/HTTP" serão todos correspondidos).

Secure Optional

Um cookie seguro apenas será enviado para o servidor quando uma requisição utilizando os protocol SSL e HTTPS for realizada. No entanto, informações confidenciais ou sensíveis não deverão ser armazenadas ou transmitidas em Cookies HTTP pois todo o mecanismo é inerentemente inseguro e isso não significa, por exemplo que qualquer informação é criptografada.

Nota: Sites inseguros (http:) não podem mais atribuir cookies com a diretiva "secure" (novo em Chrome 52+ firefox Firefox 52+).

HttpOnly Optional

Cookies HttpOnly não são acessíveis via JavaScript através da propriedade Document.cookie, as API's XMLHttpRequest e Request são utilizadas para aliviar ataques de cross-site scripting (XSS).

SameSite=Strict SameSite=Lax Optional Experimental

Permite que servidores garantam que um cookie não deve ser enviado juntamente com solicitações de sites cruzados (cross-site) , o que fornece novamente alguma proteção aos ataques de falsificação de solicitação entre sites (CSRF) (CSRF) .

Exemplos

Sessão de cookie serão removidos quando o cliente desligar. Eles não especificam as diretivas Expires ou Max-Age. Note que o navegador web tem frequentemente a opção "restaurar sessão" habilitada..

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/

Ao invés de expirar quando o cliente fecha, os cookies permantentes expiram numa data especificada (Expires), ou depois de uma duração de tempo especificada (Max-Age).

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Domínios inválidos

Um cookie pertencente a um domínio que não inclui o servidor original, deve ser rejeitado pelo agente usuário. Por exemplo: O cookie seguinte será rejeitado se foi atribuído por um servidor hospedado em originalcompany.com.

Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT

Nomes de cookies com os prefixos __Secure- e __Host- podem ser utilizados apenas de eles forem atribuídos com a diretiva secure de uma origem segura (HTTPS). Além disso, cookies com o prefixo __Host- devem ter um caminho (path) de / (o host inteiro) e não devem ter um atributo de dominio. Para clientes que não implementam prefixos de cookie, você não pode contar com essas garantias adicionais e os cookies serão sempre aceitos.

// Ambos aceitos quando de uma origem segura (HTTPS)
Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
Set-Cookie: __Host-ID=123; Secure; Path=/

// Rejeitado devido a não atribuição da diretiva Secure
Set-Cookie: __Secure-id=1

// Rejeitado devido a falta da diretiva Path=/
Set-Cookie: __Host-id=1; Secure

// Rejeitado devido a atribuição de um domínio
Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com

Especificações

Especificação Título
RFC 6265, sessão 4.1: Set-Cookie HTTP State Management Mechanism
RFC 0 Cookie Prefixes
RFC 0 Same-Site Cookies
RFC 1 Strict Secure Cookies

Compatibilidade com navegadores

Report problems with this compatibility data on GitHub
desktopmobile
Chrome
Edge
Firefox
Opera
Safari
Chrome Android
Firefox for Android
Opera Android
Safari on iOS
Samsung Internet
WebView Android
WebView on iOS
Set-Cookie
HttpOnly
Max-Age
Partitioned
SameSite
SameSite=Lax
Defaults to Lax
SameSite=None
SameSite=Strict
Secure attribute required if SameSite=None
URL scheme-aware ("schemeful")
Cookie prefixes

Legend

Tip: you can click/tap on a cell for more information.

Full support
Full support
Partial support
Partial support
No support
No support
See implementation notes.
User must explicitly enable this feature.
Has more compatibility info.

Notas de compatibilidade

  • Começando com Chrome 53 e Firefox 52, sites inseguros (http:) não podem mais atribuir cookies com a diretiva "secure".

Veja também