Toda vez que seu site WordPress define um cookie — seja para sessões de login, carrinhos de compras, análises ou preferências de consentimento — esse cookie pode carregar um conjunto de flags de segurança. Essas flags dizem ao navegador como lidar com o cookie: quando enviá-lo, quem pode lê-lo e por quais conexões pode trafegar. Errar nelas não quebra nada visivelmente, mas abre a porta para ataques que a maioria dos proprietários de sites nunca percebe até que seja tarde demais.
A Flag Secure
Um cookie com a flag Secure só será transmitido por conexões HTTPS. O navegador simplesmente se recusa a incluí-lo em qualquer requisição HTTP não criptografada.
Set-Cookie: session_id=abc123; SecurePor que isso importa? Imagine um visitante acessando seu site no Wi-Fi de uma cafeteria. Se ele acabar carregando uma página por HTTP simples — talvez por um favorito antigo ou uma má configuração de redirecionamento — seus cookies normalmente trafegariam em texto puro pela rede. Qualquer pessoa farejando o tráfego daquele Wi-Fi poderia capturar o cookie de sessão e se passar pelo usuário. Com a flag Secure, o navegador retém o cookie completamente nesse cenário.
Como seu site WordPress já deveria estar rodando em HTTPS de qualquer forma (e deveria — não há desculpa em 2025), definir essa flag não custa nada e previne uma classe real de ataques.
A Flag HttpOnly
A flag HttpOnly impede que o JavaScript acesse o cookie através de document.cookie. O cookie ainda é enviado normalmente com as requisições HTTP, mas nenhum script do lado do cliente pode lê-lo ou manipulá-lo.
Set-Cookie: session_id=abc123; HttpOnlyEsta flag existe especificamente para limitar os danos de ataques de Cross-Site Scripting (XSS). Se um atacante conseguir injetar JavaScript em sua página — através de um plugin vulnerável, um campo de comentário ou um vetor XSS armazenado — uma das primeiras coisas que esse script tentará é document.cookie para roubar tokens de sessão. Com HttpOnly ativo, essa chamada não retorna nada para os cookies protegidos.
Não previne o XSS em si. Não corrige a vulnerabilidade subjacente. Mas tira o prêmio mais valioso — cookies de sessão — da mesa, o que muitas vezes faz a diferença entre um aborrecimento e um sequestro completo de conta.
A Flag SameSite
O atributo SameSite controla o comportamento de cookies entre sites. Determina se o navegador envia um cookie quando uma requisição se origina de um domínio diferente daquele que o definiu.
Existem três valores possíveis:
SameSite=Strict— O cookie nunca é enviado com requisições entre sites. Ponto. Se alguém clicar em um link para o seu site a partir de uma página externa, o cookie de sessão não será incluído nessa primeira requisição. Esta é a configuração mais restritiva e pode causar problemas de usabilidade (usuários parecem deslogados ao chegar de links externos).SameSite=Lax— O cookie é enviado com navegações de nível superior (clicar em um link), mas não com requisições incorporadas como imagens, iframes ou envios de formulários de outros sites. Este é o padrão do navegador desde o Chrome 80 (2020) e oferece um bom equilíbrio entre segurança e usabilidade.SameSite=None— O cookie é enviado com todas as requisições, independentemente da origem. Isso é necessário para casos legítimos de uso de cookies de terceiros (formulários de pagamento incorporados, SSO, publicidade), mas deve sempre ser combinado com a flagSecure— os navegadores rejeitamSameSite=NonesemSecure.
Set-Cookie: session_id=abc123; SameSite=LaxA principal ameaça que o SameSite aborda é o Cross-Site Request Forgery (CSRF) — ataques em que um site malicioso engana seu navegador para fazer requisições autenticadas ao seu site WordPress sem o seu conhecimento.
Juntando Tudo
Para cookies de autenticação e sessão, a configuração recomendada é:
Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax; Path=/Cada flag cobre um vetor de ataque diferente:
- Secure — impede a interceptação no nível da rede
- HttpOnly — impede o roubo no nível do script (XSS)
- SameSite — impede o abuso entre origens (CSRF)
Faltar qualquer uma delas deixa uma brecha. Elas trabalham em equipe.
E os Cookies de Terceiros?
Cookies definidos por serviços externos carregados em seu site (análises, widgets de chat, pixels de publicidade) estão fora de seu controle direto. Suas flags de segurança são determinadas pelo serviço que os define. Mas você deve estar ciente deles — um cookie de terceiros sem Secure ou com SameSite=None cria exposição em seu domínio, mesmo que você não tenha definido o cookie por conta própria.
Isso é especialmente relevante para a conformidade com o GDPR: saber quais cookies são definidos em seu site e como estão configurados faz parte de sua responsabilidade como operador do site.
Como o InspectWP Ajuda
O InspectWP examina cada cookie definido durante o carregamento de uma página em seu site WordPress e sinaliza aqueles que não possuem os atributos Secure, HttpOnly ou SameSite. O relatório mostra cada cookie com suas flags atuais, para que você possa ver rapidamente quais precisam de atenção — sejam eles do núcleo do WordPress, plugins ou scripts de terceiros.