Como Corrigir Flags de Segurança de Cookies no WordPress

Se o InspectWP relata cookies sem as flags Secure, HttpOnly ou SameSite, seu site pode estar vulnerável a sequestro de sessão, roubo de cookies baseado em XSS ou ataques de cross-site request forgery (CSRF). Essas três flags são os atributos de segurança de cookies mais importantes, e funcionam juntas para proteger os dados de sessão dos seus usuários. Felizmente, corrigi-las no WordPress é simples uma vez que você entende o que cada flag faz e onde aplicá-la.

Entendendo as Flags de Segurança de Cookies e Seu Propósito

Antes de aplicar correções, ajuda entender contra o que cada flag protege:

• Flag Secure: Garante que o cookie só seja enviado por conexões HTTPS. Sem essa flag, um cookie pode ser transmitido por HTTP não criptografado, permitindo que um atacante na mesma rede (por exemplo, Wi-Fi público) o intercepte usando um simples sniffer de pacotes. Uma vez que ele tenha o cookie de sessão, pode se passar pelo usuário. Este ataque é conhecido como sequestro de sessão ou sidejacking.
• Flag HttpOnly: Impede que o JavaScript acesse o cookie via document.cookie. Esta é uma proteção crítica contra ataques de cross-site scripting (XSS). Se um atacante conseguir injetar JavaScript malicioso em sua página (através de um plugin vulnerável, campo de comentário ou entrada do usuário), a flag HttpOnly impede que esse script leia cookies de sessão e os envie para um servidor externo.
• Flag SameSite: Controla se o cookie é enviado junto com requisições entre sites. Isso protege contra ataques CSRF, onde um site malicioso engana o navegador de um usuário para fazer requisições autenticadas ao seu site. O atributo SameSite tem três valores possíveis:
  • Strict: O cookie nunca é enviado com requisições entre sites. Isso fornece a proteção mais forte, mas pode quebrar fluxos de login quando os usuários clicam em links de fontes externas como e-mails ou outros sites.
  • Lax: O cookie é enviado com navegação de nível superior (clicar em um link), mas não com requisições incorporadas (imagens, iframes, AJAX). Este é o padrão recomendado para a maioria dos sites WordPress.
  • None: O cookie é enviado com todas as requisições, incluindo as entre sites. Isso deve ser combinado com a flag Secure e só é necessário para cookies que devem funcionar em contextos entre sites, como integrações de gateway de pagamento ou widgets incorporados.

Reforçando Cookies de Autenticação do WordPress

O WordPress define vários cookies para usuários logados, incluindo wordpress_logged_in_* e wordpress_sec_*. Estes são os cookies mais sensíveis à segurança em seu site, porque controlam o acesso admin. Para reforçá-los, adicione as seguintes constantes ao seu arquivo wp-config.php, antes da linha que diz "That's all, stop editing!":

// Forçar cookies a serem enviados apenas por HTTPS
define('FORCE_SSL_ADMIN', true);

// Definir domínio e caminho do cookie
define('COOKIE_DOMAIN', 'example.com');
define('COOKIEPATH', '/');

// Reforçar cookies de sessão PHP
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_samesite', 'Lax');

A constante FORCE_SSL_ADMIN é particularmente importante. Ela força o WordPress a usar HTTPS para a área de admin e páginas de login, o que garante que os cookies de autenticação sejam definidos apenas por conexões criptografadas. Sem isso, um usuário fazendo login por HTTP teria suas credenciais e cookies transmitidos em texto puro.

Note que @ini_set só afeta cookies de sessão PHP, não os cookies específicos do WordPress. O WordPress usa suas próprias funções de definição de cookie que não dependem de sessões PHP. Para garantir cookies WordPress especificamente, você precisa das abordagens em nível de servidor descritas abaixo.

Definindo Flags de Cookie via Configuração PHP

Para PHP 7.3 e posterior, você pode definir atributos padrão de cookie que se aplicam a todos os cookies criados pela função setcookie() do PHP. Adicione estes ao seu arquivo php.ini se você tiver acesso:

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

Se você não tem acesso ao php.ini (o que é comum em hospedagem compartilhada), pode definir esses valores em seu arquivo .htaccess:

# Definir padrões de cookie seguro para sessões PHP
php_value session.cookie_secure 1
php_value session.cookie_httponly 1
php_value session.cookie_samesite "Lax"

Tenha em mente que essas configurações só se aplicam a cookies criados através do tratamento de sessão nativo do PHP. O núcleo do WordPress e a maioria dos plugins usam setcookie() ou wp_set_auth_cookie() diretamente, que não herdam automaticamente essas configurações ini. Para cobertura abrangente, a abordagem de cabeçalho em nível de servidor é mais confiável.

Corrigindo Todos os Cookies via Apache .htaccess

A maneira mais confiável de adicionar flags de segurança a cada cookie em um servidor Apache é modificar o cabeçalho Set-Cookie no nível do servidor. Isso captura todos os cookies, incluindo aqueles definidos pelo núcleo do WordPress, plugins e scripts de terceiros:

# Adicionar flags de segurança a todos os cookies
<IfModule mod_headers.c>
    Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"
</IfModule>

Coloque isso no arquivo .htaccess raiz do seu site. A diretiva Header always edit usa uma expressão regular para corresponder a todos os cabeçalhos Set-Cookie e anexa as flags de segurança a cada um.

Há uma ressalva importante com esta abordagem. Se um cookie já tiver uma dessas flags definidas (por exemplo, um plugin define Secure por conta própria), você pode acabar com flags duplicadas como Secure; Secure. A maioria dos navegadores lida com duplicatas graciosamente, mas uma abordagem mais limpa usa um lookahead negativo para evitar adicionar flags que já estão presentes:

<IfModule mod_headers.c>
    # Adicionar flag Secure se ainda não estiver presente
    Header always edit Set-Cookie "^((?!.*Secure).*)$" "$1; Secure"

    # Adicionar flag HttpOnly se ainda não estiver presente
    Header always edit Set-Cookie "^((?!.*HttpOnly).*)$" "$1; HttpOnly"

    # Adicionar SameSite=Lax se nenhum atributo SameSite estiver presente
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"
</IfModule>

Esta versão verifica cada cookie individualmente e só adiciona a flag se ela ainda não estiver lá. É mais detalhada, mas evita possíveis problemas com atributos duplicados.

Corrigindo Todos os Cookies via Configuração do Nginx

Para servidores Nginx, a abordagem depende da sua versão do Nginx:

Nginx 1.19.3 e posterior suporta a diretiva proxy_cookie_flags nativamente:

# Em seu bloco server ou location
proxy_cookie_flags ~ secure httponly samesite=lax;

O ~ corresponde a todos os cookies. Você também pode segmentar cookies específicos pelo nome:

# Aplicar apenas a cookies de sessão do WordPress
proxy_cookie_flags wordpress_logged_in_* secure httponly samesite=lax;
proxy_cookie_flags wordpress_sec_* secure httponly samesite=lax;

Versões mais antigas do Nginx (anteriores à 1.19.3) podem usar a diretiva proxy_cookie_path como solução alternativa:

# Solução alternativa para versões mais antigas do Nginx
proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";

Se você usa o Nginx como proxy reverso na frente do Apache ou PHP-FPM, talvez também precise adicionar cabeçalhos usando o módulo more_set_headers ou a diretiva add_header. No entanto, add_header não modifica cabeçalhos Set-Cookie, então proxy_cookie_flags é a abordagem correta.

Corrigindo Cookies em Sites com Cloudflare ou CDN como Proxy

Se o seu site WordPress está atrás do Cloudflare ou outro proxy CDN, o tratamento de cookies envolve uma camada extra. O Cloudflare define seus próprios cookies (como __cf_bm para gerenciamento de bots), e esses cookies são controlados pelo Cloudflare, não pela configuração do seu servidor. Você não pode adicionar flags de segurança a cookies do Cloudflare via .htaccess ou config do Nginx.

Os cookies do Cloudflare já incluem as flags Secure e HttpOnly por padrão. Se o InspectWP sinaliza um cookie do Cloudflare como faltando uma flag, é provavelmente um problema de exibição ou um cookie de um recurso do Cloudflare que intencionalmente omite certas flags (por exemplo, cookies de análise que precisam de acesso JavaScript podem não ter HttpOnly).

Para cookies definidos pelo seu servidor de origem, as correções de .htaccess ou Nginx descritas acima ainda funcionam corretamente mesmo quando o Cloudflare está na frente. O Cloudflare passa os cabeçalhos Set-Cookie do seu servidor para o cliente sem modificação.

Lidando com Cookies de Plugins Que Não Têm Flags de Segurança

Muitos plugins WordPress definem seus próprios cookies, e nem todos eles incluem flags de segurança adequadas. Os infratores comuns incluem:

• Plugins de consentimento de cookies: Plugins como CookieYes, Complianz ou GDPR Cookie Consent definem cookies para lembrar a escolha de consentimento do usuário. Verifique nas configurações de cada plugin uma opção "Cookies seguros" ou "Segurança de cookies". Alguns plugins adicionaram essas opções em versões recentes.
• Plugins de análise e rastreamento: Google Analytics, Matomo e plugins similares podem definir cookies de rastreamento sem flags de segurança. A abordagem de cabeçalho em nível de servidor (Apache/Nginx) é a melhor correção para esses, já que os plugins raramente oferecem configuração de flag de cookie.
• Plugins de cache: WP Rocket, LiteSpeed Cache e outros definem cookies identificadores de cache que podem não ter flags. Novamente, a abordagem em nível de servidor lida com esses automaticamente.
• WooCommerce: O WooCommerce define vários cookies para dados de carrinho e gerenciamento de sessão. Versões recentes do WooCommerce (5.0+) definem a flag Secure quando o site usa HTTPS, mas versões mais antigas podem não fazê-lo. Atualize o WooCommerce para a versão mais recente e aplique a correção de cabeçalho em nível de servidor como uma rede de segurança.
• Plugins de login e associação: Plugins como MemberPress, Restrict Content Pro ou WP-Members podem definir seus próprios cookies de sessão. Verifique se há atualizações de plugin, pois muitos adicionaram suporte a flag de segurança em resposta às mudanças no navegador em torno da aplicação de SameSite.

A abordagem em nível de servidor (Apache Header edit ou Nginx proxy_cookie_flags) é a solução mais confiável porque captura todos os cookies, independentemente de qual plugin ou script os define. Mesmo que uma atualização de plugin remova as flags, a configuração do seu servidor as adiciona de volta.

Considerações Especiais para Cookies SameSite=None

Algumas funcionalidades exigem que cookies sejam enviados em contextos entre sites. Exemplos comuns incluem:

• Callbacks de gateway de pagamento: Serviços como PayPal, Stripe ou Mollie podem redirecionar usuários de volta ao seu site após o pagamento. Se seu cookie de sessão usa SameSite=Strict, o usuário será deslogado após o redirecionamento porque o navegador não envia o cookie com a navegação entre sites.
• Conteúdo incorporado (iframes): Se seu site WordPress está incorporado em um iframe em outro domínio, os cookies precisam de SameSite=None; Secure para funcionar. Isto é relevante para configurações WordPress headless ou sites que fornecem widgets incorporáveis.
• Fluxos OAuth e SSO: Implementações de single sign-on que redirecionam através de provedores de identidade de terceiros podem exigir SameSite=None para o cookie de sessão durante o fluxo de autenticação.

Se você precisa de SameSite=None para cookies específicos, mantendo SameSite=Lax como padrão, precisará de uma configuração mais direcionada. No Apache:

<IfModule mod_headers.c>
    # Padrão: adicionar SameSite=Lax a todos os cookies
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"

    # Substituir para cookies específicos que precisam de acesso entre sites
    Header always edit Set-Cookie "(payment_session=.*)" "$1; SameSite=None; Secure"
</IfModule>

Adicionando Segurança de Cookies via um Plugin WordPress

Se você não tem acesso aos arquivos de configuração do servidor (comum em hospedagem WordPress gerenciada), pode usar um plugin WordPress para adicionar flags de segurança de cookies. A abordagem do plugin funciona conectando-se ao filtro wp_headers ou usando a função header() do PHP para modificar cabeçalhos Set-Cookie antes de serem enviados ao navegador:

function add_cookie_security_flags($headers) {
    // Isso afeta cabeçalhos enviados pelo WordPress
    if (is_ssl()) {
        $headers['Set-Cookie'] = 'Secure; HttpOnly; SameSite=Lax';
    }
    return $headers;
}
add_filter('wp_headers', 'add_cookie_security_flags');

// Para segurança de cookies em nível de PHP
function enforce_cookie_security() {
    if (is_ssl() && PHP_VERSION_ID >= 70300) {
        ini_set('session.cookie_secure', '1');
        ini_set('session.cookie_httponly', '1');
        ini_set('session.cookie_samesite', 'Lax');
    }
}
add_action('init', 'enforce_cookie_security', 1);

Esta abordagem tem limitações. Ela só afeta cookies definidos depois que o hook init do WordPress dispara, e não pode modificar cookies definidos por JavaScript ou por scripts externos. A abordagem em nível de servidor é sempre mais abrangente.

Verificando Flags de Segurança de Cookies Após Aplicar Correções

Após implementar suas correções, testes completos são essenciais para confirmar que tudo funciona corretamente:

1. Limpe todos os cookies do navegador: Abra as ferramentas de desenvolvedor do seu navegador, vá para a aba Application (Chrome) ou Storage (Firefox) e exclua todos os cookies do seu domínio. Isso garante que você está testando cookies novos com as novas flags.
2. Visite seu site e faça login: Após fazer login, volte às ferramentas de desenvolvedor e inspecione cada cookie. No Chrome, o painel Application > Cookies mostra colunas para Secure, HttpOnly e SameSite. Cada cookie de autenticação deve mostrar uma marca de verificação para Secure e HttpOnly, e exibir "Lax" para SameSite.
3. Teste fluxos críticos do usuário: Navegue pela funcionalidade-chave do seu site: adicione itens a um carrinho (se WooCommerce), envie formulários, passe pelo processo de checkout e use quaisquer recursos de associação. Mudanças de SameSite podem ocasionalmente quebrar fluxos entre sites, então teste qualquer coisa que envolva redirecionamentos de serviços externos.
4. Teste login a partir de links externos: Envie a si mesmo um e-mail de redefinição de senha e clique no link. Se você usou SameSite=Strict (não recomendado), esse fluxo pode quebrar porque o cookie não será enviado com a navegação entre sites do cliente de e-mail.
5. Execute o InspectWP novamente: Faça uma nova varredura do seu site com o InspectWP para confirmar que todos os avisos de segurança de cookies foram resolvidos. O InspectWP verifica cada cookie individualmente, para que você possa ver exatamente quais cookies agora têm as flags corretas.

Solução de Problemas Comuns Após Habilitar Flags de Segurança de Cookies

• Usuários são deslogados após clicar em links de e-mail: Isso acontece quando SameSite=Strict é definido. Mude para SameSite=Lax, que permite cookies em navegações de nível superior de sites externos enquanto ainda bloqueia requisições entre sites incorporadas.
• Integração de gateway de pagamento quebra: Alguns processadores de pagamento redirecionam usuários através de seu próprio domínio durante o checkout. Se o cookie de sessão não é enviado após o redirecionamento, o usuário perde seu carrinho ou estado de login. Defina o cookie de sessão de pagamento como SameSite=None; Secure especificamente, mantendo outros cookies em SameSite=Lax.
• Banner de consentimento de cookies continua reaparecendo: Se o cookie do plugin de consentimento de cookies é definido sem a flag Secure e seu site redireciona HTTP para HTTPS, o cookie definido em HTTP não é enviado por HTTPS, fazendo com que o banner apareça novamente. Garanta que seu site rode totalmente em HTTPS e que o cookie de consentimento inclua a flag Secure.
• Conflitos de cache: Alguns plugins de cache fazem cache dos cabeçalhos Set-Cookie junto com o conteúdo da página. Após aplicar mudanças de flag de cookie em nível de servidor, limpe seu cache inteiro (tanto cache de página quanto cache de objetos) para garantir que os novos cabeçalhos tenham efeito.
• Flags de cookie duplicadas: Se você vê atributos como Secure; Secure ou SameSite=Lax; SameSite=Lax em seus cookies, você tem múltiplas camadas adicionando as mesmas flags. Verifique seu .htaccess, wp-config.php, configurações ini do PHP e quaisquer plugins de segurança para configurações sobrepostas. Use a abordagem de regex de lookahead negativo no .htaccess para evitar duplicatas.

Melhores Práticas de Segurança de Cookies para WordPress

• Sempre use HTTPS: A flag Secure é sem sentido sem HTTPS. Garanta que todo o seu site carregue por HTTPS, incluindo todos os recursos (imagens, scripts, folhas de estilo). Use a constante FORCE_SSL_ADMIN e considere um cabeçalho HSTS para impedir qualquer acesso HTTP.
• Padrão para SameSite=Lax: Isto fornece forte proteção CSRF sem quebrar a navegação normal. Use SameSite=None apenas para cookies específicos que genuinamente exigem acesso entre sites, e use SameSite=Strict apenas se você tiver certeza de que nenhuma navegação externa para o seu site precisa manter sessões.
• Aplique flags em nível de servidor: A configuração em nível de servidor (Apache .htaccess ou config do Nginx) captura todos os cookies, independentemente da origem. Isto é mais confiável do que abordagens em nível de plugin ou PHP.
• Mantenha o WordPress e plugins atualizados: Versões modernas do núcleo do WordPress e da maioria dos plugins populares definem flags de cookie adequadas quando o HTTPS está ativo. Manter tudo atualizado reduz o número de cookies inseguros que você precisa corrigir em nível de servidor.
• Audite cookies regularmente: Execute varreduras periódicas do InspectWP para detectar novos cookies introduzidos por atualizações de plugin ou novas integrações. Segurança de cookies não é uma correção única; requer atenção contínua à medida que seu site evolui.
• Teste em múltiplos navegadores: Chrome, Firefox, Safari e Edge cada um trata atributos de cookie de forma ligeiramente diferente. O Chrome é o mais rigoroso enforcer de políticas SameSite, enquanto o Safari tem sua própria Intelligent Tracking Prevention que afeta o comportamento de cookies. Teste seu site em todos os principais navegadores após fazer mudanças.