Certificado SSL/TLS e HTTPS: como o certificado, o HSTS, a CSP e os cookies protegem o site

1. Entenda o papel do certificado

Quando o navegador se conecta por HTTPS, o TLS negocia uma conexão criptografada. O navegador confere se o certificado vale para o nome pedido e se foi emitido por uma autoridade em que ele confia. O certificado informa os nomes que cobre, o período de validade e os dados necessários para montar a cadeia de confiança até essa autoridade.

Faça uma lista dos nomes públicos: o domínio raiz, o www e subdomínios de serviço, como loja, api ou status. Confira cada nome e anote quem cuida do certificado dele. Uma CDN e o servidor de origem podem ter certificados diferentes, renovados de formas diferentes. As orientações de TLS da OWASP pedem que aplicações web usem o TLS 1.3 por padrão, admitem o TLS 1.2 por compatibilidade e mandam desativar o TLS 1.0 e o 1.1. Registrar o protocolo negociado em uma conexão real dá à revisão uma observação concreta.

Os prazos de validade estão ficando mais curtos, e isso muda a rotina. Pela votação SC081v3 do CA/Browser Forum, certificados públicos emitidos a partir de 15 de março de 2026 valem no máximo 200 dias; o limite cai para 100 dias em março de 2027 e para 47 dias em março de 2029. O Let's Encrypt ainda emite certificados de 90 dias por padrão, mas vai reduzir esse prazo para 64 dias em fevereiro de 2027 e para 45 dias em fevereiro de 2028; renovar em um intervalo fixo de 60 dias deixará de funcionar. Ele também deixou de enviar avisos de expiração por e-mail em junho de 2025. Por isso, a renovação precisa ser automática, e vale ter um monitoramento de validade que não dependa da autoridade certificadora.

2. Veja como as camadas se complementam

Pense nesses controles como instruções que se completam. O certificado cuida da conexão; os cabeçalhos dizem como cada resposta deve se comportar. Páginas diferentes podem pedir políticas diferentes: um artigo público, a área da conta e um widget feito para ser incorporado em outros sites têm necessidades distintas, e a configuração deve refletir isso. Segundo a OWASP, cabeçalhos bem configurados ajudam a evitar classes de problemas como XSS, clickjacking e exposição de informações. Eles não substituem, porém, um código que trate corretamente os dados recebidos.

3. Construa a CSP a partir dos recursos que o site usa

A Content Security Policy diz ao navegador de quais origens a página pode carregar scripts, estilos, imagens, fontes, conexões e frames, e quais comportamentos são permitidos. Comece por um inventário desses recursos e percorra a jornada inteira, não só a página inicial. Pagamento, login, chat de suporte e qualquer recurso que só aparece depois de um clique precisam estar na lista.

Antes de aplicar a política, use o modo Report-Only. O cabeçalho Content-Security-Policy-Report-Only não bloqueia nada: ele só informa o que seria bloqueado, no console do navegador ou no endereço de relatórios configurado. Relacione cada mensagem a um recurso, decida a regra e, depois de testar as jornadas representativas, publique a política no cabeçalho Content-Security-Policy. Os dois cabeçalhos podem conviver, o que permite testar uma versão mais rígida enquanto a atual continua valendo. O modo Report-Only só funciona como cabeçalho HTTP; ele não pode ser declarado em uma tag <meta>.

Para scripts, o guia de CSP da MDN recomenda nonces ou hashes, que autorizam scripts específicos, no lugar de listas longas de domínios. Evite 'unsafe-inline', que anula boa parte da proteção. Scripts de terceiros que carregam outros scripts tornam essa política mais trabalhosa, e vale saber disso antes de começar. A CSP é uma camada a mais e não substitui a validação e o tratamento das entradas. Um inventário documentado facilita avaliar recursos novos e explica à equipe o motivo de cada permissão.

4. Faça do HTTPS um hábito do navegador

O cabeçalho Strict-Transport-Security (HSTS) diz ao navegador para usar só HTTPS com aquele host durante o período definido em max-age, em segundos. O navegador aprende a regra em uma resposta HTTPS válida e a aplica nas visitas seguintes; se o cabeçalho chegar por HTTP simples, é ignorado. Por isso, quem leva o cabeçalho é a resposta HTTPS, e não o redirecionamento de HTTP para HTTPS. Comece com um prazo curto, que a equipe consiga revisar, confirme o comportamento e aumente aos poucos. O hstspreload.org sugere subir em etapas (cinco minutos, uma semana, um mês) e conferir a cada passo se nada quebrou.

Com HSTS ativo, o navegador não oferece a opção de ignorar um erro de certificado. Isso é intencional, mas significa que um certificado vencido deixa o site inacessível para quem já o visitou. A opção includeSubDomains estende a regra a todos os subdomínios, então só a ative depois de confirmar que todos eles funcionam por HTTPS, inclusive os que ninguém lembra de testar. Mesmo assim, cada subdomínio deve enviar o próprio cabeçalho, porque o navegador pode nunca visitar o domínio raiz.

O preload coloca o domínio em uma lista embutida nos navegadores e cobre até a primeira visita. Trate essa opção como uma decisão de longo prazo: sair da lista leva meses. Hoje o próprio hstspreload.org recomenda o HSTS, mas não o preload, porque navegadores como Chrome e Safari já levam as navegações para HTTPS automaticamente. Algumas referências, como o valor recomendado na página de cabeçalhos HTTP da OWASP, ainda incluem preload; não copie esse valor sem ter tomado essa decisão. A explicação da MDN sobre HSTS mostra como as opções se combinam.

5. Ajuste cookies e cabeçalhos à jornada

O cookie de sessão é o que permite ao serviço reconhecer uma visita que continua. Três atributos definem como ele circula:

• Secure: o navegador só envia o cookie em requisições HTTPS (localhost é exceção). Esse atributo não esconde o cookie do JavaScript.
• HttpOnly: impede que o JavaScript da página leia o cookie, por exemplo via document.cookie. O cookie não fica criptografado e continua sendo enviado normalmente nas requisições ao site, inclusive nas feitas por fetch(). Assim, o HttpOnly dificulta o roubo da sessão em caso de XSS, mas não impede o XSS em si.
• SameSite: controla se o cookie vai junto em requisições entre sites, com os valores Strict, Lax ou None. Os navegadores não têm todos o mesmo padrão quando o atributo falta, então defina-o explicitamente. Um cookie com SameSite=None precisa também de Secure.

Escolha a combinação pensando no fluxo real de login e de retorno: um pagamento que volta de outro domínio ou um login social podem precisar de Lax em vez de Strict, e isso só aparece testando. Como lembram as orientações de gestão de sessão da OWASP, o SameSite é uma defesa extra contra CSRF e não substitui os tokens anti-CSRF. A referência da MDN sobre Set-Cookie detalha cada atributo.

Outros cabeçalhos completam o quadro:

• X-Content-Type-Options: nosniff faz o navegador bloquear scripts e folhas de estilo servidos com o tipo MIME errado e parar de adivinhar o tipo das outras respostas. Para funcionar bem, o Content-Type precisa estar correto em todo o site.
• Referrer-Policy define quanto da URL de origem segue junto nas requisições. Sem ele, os navegadores atuais usam strict-origin-when-cross-origin, mas a OWASP recomenda enviá-lo explicitamente por causa dos navegadores mais antigos.
• Para controlar quem pode exibir a página em um frame, use a diretiva frame-ancestors da CSP, enviada como cabeçalho HTTP. Ela não funciona em <meta> e não herda o valor de default-src: uma política com default-src 'none' ainda deixa qualquer site incorporar a página. X-Frame-Options: DENY ou SAMEORIGIN continua útil para navegadores antigos; o valor ALLOW-FROM é obsoleto e faz o navegador ignorar o cabeçalho inteiro.
• Permissions-Policy desliga recursos do navegador que o site não usa, como câmera, microfone e geolocalização. A OWASP recomenda desativar tudo o que não for necessário.
• X-XSS-Protection está obsoleto: deixe o site sem esse cabeçalho, ou com o valor 0, e use a CSP.

A referência de cabeçalhos da OWASP ajuda a escolher os valores. No nginx, use add_header com a opção always; sem ela, o cabeçalho só sai em alguns códigos de status, e as páginas de erro ficam sem proteção. Anote a finalidade de cada cabeçalho para que aplicação, proxy e CDN expressem uma política coerente, sem duplicar nem sobrescrever valores.

6. Observe a experiência concluída

Abra as ferramentas de desenvolvedor do navegador na aba Rede, carregue uma página comum e siga os redirecionamentos até a resposta final. Confira o certificado, os cabeçalhos e os cookies que de fato chegaram. Pela linha de comando, curl -sI https://example.com/ mostra os cabeçalhos da resposta, e curl -sI http://example.com/ mostra se o endereço HTTP redireciona para HTTPS. O esperado é um redirecionamento permanente (301 ou 308) para o mesmo endereço em HTTPS, no mesmo host. Assim você liga a configuração à experiência real do visitante e descobre qual serviço contribui com cada valor. Para conferir os cabeçalhos um a um no DevTools ou com curl, com valores iniciais seguros, veja o guia para verificar os cabeçalhos de segurança HTTP.

1. Visite cada nome público da lista por HTTPS e também pela versão HTTP, para ver o redirecionamento.
2. Registre os dados do certificado (emissor, nomes cobertos, validade) e os cabeçalhos da resposta final.
3. Complete login, recuperação de senha, pagamento incorporado e retornos de sites externos.
4. Leia as mensagens do console e o destino dos relatórios de CSP.

Guarde um registro datado da configuração e de quem cuida de cada camada. Quando a hospedagem ou uma integração mudar, repita o mesmo percurso para confirmar o comportamento esperado. Uma implantação planejada, com a configuração anterior à mão para voltar atrás se for preciso, deixa as atualizações mais tranquilas. O mesmo checklist serve de introdução prática ao site para quem chegar depois à equipe.

Para verificar agora os cabeçalhos de um site, use o verificador de cabeçalhos de segurança HTTP gratuito.

7. Mantenha o mapa de proteção perto do site

Reúna em um só lugar os nomes públicos, os responsáveis pelos certificados, os recursos que cada página carrega e as jornadas importantes. Para uma leitura externa rápida, o snapshot gratuito de prontidão para lançamento do Sitelemetry roda oito verificações passivas em uma origem pública, sem cadastro, entre elas o certificado TLS e os cabeçalhos de segurança da página inicial. Ele faz um único handshake e avalia se a cadeia é confiável, se o certificado vence em até 30 dias e se o protocolo negociado é o TLS 1.2 ou o 1.3; nos cabeçalhos, verifica principalmente se cada um está presente. Não é um pentest. Se ele apontar um HSTS com max-age curto (menos de 180 dias) enquanto você sobe o prazo em etapas, trate o aviso como um lembrete de revisão.

O guia de auditoria de segurança de site mostra como essas camadas se ligam a contas, permissões e à manutenção do dia a dia, e o guia de SPF, DKIM e DMARC cobre o lado do domínio e do e-mail.