O que realmente quebra em SameSite Lax vs Strict vs None

Qual é a diferença entre SameSite Lax vs Strict vs None?

Navegadores leem SameSite Lax vs Strict vs None como três respostas para uma única pergunta: quais requisições cross-site podem carregar este cookie. A RFC 6265bis apresenta as três em um único parágrafo da seção 4.1.2.7: "If the 'SameSite' attribute's value is 'Strict', the cookie will only be sent along with 'same-site' requests. If the value is 'Lax', the cookie will be sent with same-site requests, and with 'cross-site' top-level navigations, as described in Section 5.6.7.1. If the value is 'None', the cookie will be sent with same-site and cross-site requests."

O rascunho em vigor é o draft-ietf-httpbis-rfc6265bis-22, de 1 de dezembro de 2025, editado por Bingler, West e Wilander, e marcado como "Obsoletes: 6265 (if approved)". O atributo limita o escopo por site e não por origem, então https://www.site.example e https://api.site.example são o mesmo site, e a decisão sobre dois hosts compartilharem ou não um site cabe à public suffix list, não apenas ao domínio registrável.

O que o Lax permite que o Strict não permite?

O Lax permite exatamente uma classe extra de requisição: uma navegação cross-site de nível superior que usa um método HTTP seguro. A RFC declara a exceção e seu propósito na mesma frase, chamando o Lax de "a drop-in mechanism that mitigates the risk of CSRF attacks" que "sends same-site cookies along with cross-site requests if and only if they are top-level navigations which use a 'safe' (in the [HTTP] sense) HTTP method."

A MDN transforma isso no teste que você aplica na prática. Uma navegação de nível superior "essentially means that the request causes the URL shown in the browser's address bar to change", o que inclui um link clicado, uma atribuição a document.location e o envio de um <form>, e exclui "requests made using the fetch() API, or requests for subresources from <img> or <script> elements, or navigations inside <iframe> elements." A metade sobre método seguro "excludes POST, PUT, and DELETE."

A RFC é honesta sobre o que o Lax não entrega. "Lax enforcement provides reasonable defense in depth against CSRF attacks that rely on unsafe HTTP methods (like POST), but does not offer a robust defense against CSRF as a general category of attack", já que "Attackers can still pop up new windows or trigger top-level navigations in order to create a 'same-site' request".

Qual é o padrão documentado do Chrome para SameSite?

O Chrome trata um cookie sem atributo SameSite como Lax, e documenta uma exceção deliberada. A própria referência do Google enuncia a regra: "If you send a cookie without specifying its SameSite attribute, the browser treats that cookie as if it were set to SameSite=Lax." A mesma página acrescenta a exceção em uma caixa de alerta: "Chrome's default behavior is slightly more permissive than an explicit SameSite=Lax, because it lets sites send some cookies on top-level POST requests. For details, see the blink-dev announcement. This is intended as a temporary mitigation."

Essa página traz data de última atualização de 7 de maio de 2019 e uma tabela de suporte que lista Chrome 80 e Edge 86 para a mudança de padrão, Firefox atrás de uma flag e Safari sem suporte. Desde então a IETF formalizou a exceção que o Chrome chama de temporária. A RFC 6265bis a batiza de "Lax-allowing-unsafe" e a especifica: os user agents "MAY apply 'Lax-allowing-unsafe' enforcement only to cookies that did not explicitly specify a SameSite attribute", "SHOULD restrict the enforcement to cookies which were created recently", e "Deployment experience has shown a cookie age of 2 minutes or less to be a reasonable limit." A MDN repete o mesmo número do lado do navegador: sob um Lax aplicado por padrão, "cookies are also included in POST requests, as long as they were set no more than two minutes before the request was made."

Duas consequências decorrem daí, e as duas pegam gente de surpresa. Escrever SameSite=Lax de forma explícita é mais restritivo do que não escrever nada, porque a RFC aplica o Lax-allowing-unsafe apenas a cookies cuja flag foi definida como "Default" por ausência. E "Lax-allowing-unsafe is not a distinct value of the SameSite attribute", então não existe string que você possa enviar para pedir esse comportamento.

A especificação trata um erro de digitação do mesmo jeito. "If the 'SameSite' attribute's value is something other than these three known keywords, the attribute's value will be subject to a default enforcement mode that is equivalent to 'Lax'." Um cookie enviado com SameSite=Laxx não é rejeitado; ele é silenciosamente tratado como se o atributo não existisse.

Por que SameSite=None precisa carregar Secure?

Um cookie que declara SameSite=None sem Secure é jogado fora, e a RFC coloca isso no algoritmo de armazenamento em vez de deixar como conselho. O passo 19 da seção 5.7 diz: "If the cookie's 'same-site-flag' is 'None', abort this algorithm and ignore the cookie entirely unless the cookie's secure-only-flag is true."

A referência do Google diz o mesmo para quem desenvolve, "When you create cross-site cookies using SameSite=None, you must also set them to Secure for the browser to accept them", e mostra o cabeçalho completo:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

A redação da MDN é igualmente direta: para None, "The Secure attribute must also be set when using this value." Não existe no fluxo do console nenhum aviso que a maioria das pessoas leia como aviso, porque o cookie simplesmente nunca é armazenado. Se uma integração cross-site funciona na sua máquina e falha em produção, verifique antes se a resposta definiu SameSite=None sobre HTTP puro.

O Partitioned se soma a isso, e não o substitui. Os navegadores aceitam esse atributo apenas junto de SameSite=None, assunto coberto em como os cookies particionados CHIPS dão a cada site o próprio pote.

O que quebra em cada modo?

A RFC ilustra a falha do Strict com um cenário em vez de uma regra. Uma pessoa lendo e-mail em https://site.example clica em um link para https://projects.example/secret/project: "if https://projects.example has marked their session cookies as SameSite=Strict, then this cross-site navigation won't send them along with the request. https://projects.example will render a 404 error to avoid leaking secret information, and the user will be quite confused." O Strict faz cada link de entrada vindo de busca, e-mail, chat e redes sociais parecer uma visita deslogada na primeira renderização.

A correção que ela prescreve são dois cookies em vez de um, "one conceptually granting 'read' access, another granting 'write' access. The latter could be marked as SameSite=Strict, and its absence would prompt a reauthentication step before executing any non-idempotent action. The former could be marked as SameSite=Lax."

O Lax quebra um conjunto mais estreito de coisas, e a RFC nomeia a mais afiada: "the concluding step of a login flow may involve a cross-site top-level POST request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login." Sob Lax explícito esse cookie fica de fora por causa do método, "resulting in an unrecoverable failure of the whole login flow." Single sign-on e os saltos de retorno de pagamento falham do mesmo jeito.

O None não quebra nada por regra e quebra tudo por política. A RFC identifica os casos que precisam dele, "content intended for embedding in cross-site contexts (social networking widgets or commenting services, for instance) will not have access to same-site cookies. Cookies which are required in these situations should be marked with SameSite=None", e acrescenta que "some forms of Single-Sign-On might require cookie-based authentication in a cross-site context". Um cookie SameSite=None; Secure é um cookie de terceiros em todo sentido que importa para os controles de privacidade de um navegador, então ele herda cada restrição que esses controles aplicam. Essa herança é a história inteira em só o domínio decide entre cookies primários e de terceiros e em o que o limite de 7 dias de cookies do Safari realmente restringe.

Uma resposta cross-site pode definir um cookie Lax ou Strict?

Não, e essa regra é separada da entrega. A seção 4.1.2.7 afirma que "The 'SameSite' attribute affects cookie creation as well as delivery. Cookies which assert 'SameSite=Lax' or 'SameSite=Strict' cannot be set in responses to cross-site subresource requests, or cross-site nested navigations. They can be set along with any top-level navigation, cross-site or otherwise."

Ou seja, um widget embutido carregado em um <iframe> na página de outra pessoa não consegue escrever um cookie Lax de jeito nenhum, quaisquer que sejam suas intenções. O único cookie que ele consegue escrever é SameSite=None; Secure. Scripts de analytics servidos a partir de um domínio compartilhado de fornecedor esbarram nisso o tempo todo, e essa é uma das razões pelas quais a hospedagem de script em domínio próprio e a decoração de link que a Apple mira foram parar no centro do desenho de medição.

Perguntas frequentes

Qual valor de SameSite um cookie de sessão deve usar?

Lax para um cookie de sessão que precisa sobreviver a um link de entrada, já que a RFC chama o Lax de "drop-in mechanism that mitigates the risk of CSRF attacks". Strict para qualquer coisa que proteja uma ação que altera estado, seguindo o padrão de dois cookies da RFC, no qual a ausência da metade Strict "would prompt a reauthentication step before executing any non-idempotent action."

Omitir SameSite é a mesma coisa que escrever SameSite=Lax?

No Chrome, não. O Google documenta o padrão como mais permissivo: ele "lets sites send some cookies on top-level POST requests." A RFC 6265bis restringe esse comportamento Lax-allowing-unsafe a "cookies that did not explicitly specify a SameSite attribute", com um limite de idade recomendado de "2 minutes or less". Escrever o atributo por extenso entrega um comportamento mais restritivo do que deixá-lo de fora.

SameSite=None exige HTTPS?

Sim, de forma indireta, porque exige Secure e cookies Secure ficam confinados a protocolos seguros. O passo 19 da RFC 6265bis descarta o cookie na hora: ignore-o "unless the cookie's secure-only-flag is true."

O SameSite sozinho impede CSRF?

Não. A RFC diz que o Lax "does not offer a robust defense against CSRF as a general category of attack" e orienta quem desenvolve a "more completely mitigate CSRF through a session management mechanism". A orientação do Google acrescenta que "Neither Strict nor Lax is a complete solution for your site's security."

O que acontece se eu enviar um valor inválido de SameSite?

Ele é tratado como se você não tivesse enviado nada. Pela seção 4.1.2.7, um valor "other than these three known keywords" recebe "a default enforcement mode that is equivalent to 'Lax'", e o algoritmo de armazenamento define a same-site-flag do cookie como "Default". Maiúsculas e minúsculas não importam, já que a RFC compara "None", "Strict" e "Lax" sem diferenciar caixa.

O SameSite é decidido por domínio ou por site?

Por site, que é mais amplo que origem e mais estreito que domínio. Subdomínios de um mesmo site registrável são same-site entre si, e a referência do Google aponta a fronteira que pega as pessoas de surpresa: a public suffix list "doesn't just depend on top-level domains like .com, but can also include services like github.io", então your-project.github.io e my-project.github.io são sites separados.

Por que links de e-mail ou de busca quebram com SameSite=Strict?

A RFC descreve exatamente esse caso: um usuário lendo e-mail clica em um link para um site com cookies de sessão SameSite=Strict, e a navegação cross-site não envia esses cookies junto. O site de destino mostra um erro 404 para não vazar dados, e o usuário vê o que parece uma página deslogada no primeiro carregamento. A solução proposta pela RFC é usar dois cookies em vez de um, com apenas o cookie de escrita marcado como Strict e o de leitura como Lax.

Por que um fluxo de login falha com SameSite=Lax?

Alguns fluxos de login terminam com um POST cross-site de nível superior para um endpoint que espera um cookie criado há pouco com dados da transação. Um cookie SameSite=Lax explícito fica de fora dessa requisição porque POST não é um método seguro, o que a RFC descreve como "unrecoverable failure of the whole login flow". O login único e os retornos de pagamento falham pelo mesmo motivo.

Um widget em um iframe cross-site pode definir um cookie Lax?

Não. A seção 4.1.2.7 estabelece que cookies com SameSite=Lax ou SameSite=Strict não podem ser definidos em respostas a requisições cross-site de subrecursos nem a navegações aninhadas cross-site, o que cobre um iframe incorporado na página de outro site. O único cookie que esse widget pode definir é SameSite=None com Secure.

Qual é a relação do atributo Partitioned com SameSite=None?

Partitioned se soma ao SameSite=None em vez de substituí-lo. Os navegadores só aceitam o atributo Partitioned junto com SameSite=None, que é como o CHIPS dá a cada site seu próprio pote de cookies mantendo as exigências de None e Secure.