Segurança básica de um site: HTTPS, cabeçalhos e scripts

Num site público, o primeiro passo de segurança é conferir o que qualquer visitante (ou atacante) enxerga de fora: se todo acesso vai para HTTPS, se o servidor aceita só TLS 1.2 e 1.3 com um certificado válido, se os cabeçalhos de segurança estão presentes, se a página carrega algo por HTTP, se há arquivos como .env, .git ou backups acessíveis, se o CMS e os plugins estão atualizados, quais scripts de terceiros rodam na página e como os cookies são gravados. Esses itens cobrem configuração e exposição. Eles não dizem se o código tem falhas, se as senhas estão bem guardadas ou se o painel administrativo resiste a ataques.

Este guia vale para sites e lojas virtuais acessados pelo navegador, com as normas e recomendações em vigor em outubro de 2026. Cada seção explica o item, como conferir e onde aprofundar. Os detalhes de cada cabeçalho estão no artigo sobre cabeçalhos HTTP de segurança, e as regras para scripts em páginas de pagamento estão no texto sobre o PCI DSS 4.0 e os requisitos 6.4.3 e 11.6.1.

O que uma verificação externa vê e o que não vê

Uma verificação externa faz requisições ao site como um navegador faria e analisa as respostas: status HTTP, redirecionamentos, cabeçalhos, certificado, HTML e os recursos que a página pede. O HTTP Observatory, ferramenta gratuita da Mozilla, segue essa linha. A própria documentação dele diz que o teste foca em dados HTTP e não procura versões desatualizadas de software, injeção de SQL, plugins vulneráveis de CMS nem armazenamento inadequado de senhas (FAQ do HTTP Observatory).

Por isso uma nota alta numa ferramenta externa mostra que as proteções básicas de configuração estão no lugar. Ela não atesta que o site é seguro. A Mozilla faz o mesmo alerta: quem tem nota boa não deve deixar de lado os problemas que a ferramenta não testa (FAQ do HTTP Observatory).

Uma ressalva antes de começar: ler cabeçalhos e certificado é o que qualquer navegador faz. Procurar arquivos escondidos ou forçar protocolos antigos já é teste ativo, e só deve ser feito em sites que você administra ou com autorização do responsável.

HTTPS e o redirecionamento de http para https

HTTPS é o HTTP dentro de uma conexão cifrada com TLS (Transport Layer Security), o protocolo que protege os dados entre o navegador e o servidor. O site inteiro deve responder em HTTPS, e quem chega por http:// deve ser redirecionado para o mesmo endereço em https://. A orientação da Mozilla é que, na porta 80, o servidor só redirecione para o mesmo recurso em HTTPS. Se o domínio final for outro (por exemplo, sem e com www), o primeiro salto deve ir para HTTPS no mesmo host, e só depois para o outro host (MDN: guia prático de TLS). O HTTP Observatory penaliza o caso em que o primeiro salto já troca de host (FAQ do HTTP Observatory).

Para conferir no terminal, peça só os cabeçalhos da versão http:

curl -sI http://exemplo.com.br/

A resposta esperada é um 301 ou 308 com Location: https://exemplo.com.br/. Um 200 em http significa que o site ainda serve conteúdo sem cifra. APIs e áreas que não são para o público podem simplesmente desligar o HTTP (MDN: guia prático de TLS). Cadeias longas de redirecionamento também atrasam a página; o artigo sobre redirecionamentos, cadeias e loops trata desse lado.

Versão do TLS e validade do certificado

O TLS 1.0 e o TLS 1.1 foram descontinuados pela IETF em 2021: a RFC 8996 diz que nenhum dos dois deve ser usado nem negociado (RFC 8996). O OWASP ASVS 5.0, padrão de verificação de segurança de aplicações, pede que só as versões recomendadas estejam ativas, como TLS 1.2 e TLS 1.3, com a mais nova como preferida (ASVS 5.0, requisito 12.1.1), e que serviços expostos usem certificados emitidos por autoridades confiáveis publicamente (requisito 12.2.2).

Para ver se o servidor ainda aceita TLS 1.1 e quando o certificado vence, o OpenSSL resolve:

# deve falhar se o TLS 1.1 estiver desligado
openssl s_client -connect exemplo.com.br:443 -servername exemplo.com.br -tls1_1 </dev/null

# datas de início e fim do certificado
openssl s_client -connect exemplo.com.br:443 -servername exemplo.com.br </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

O prazo dos certificados está encurtando. Em abril de 2025 o CA/Browser Forum, que reúne autoridades certificadoras e navegadores, aprovou a redução gradual da validade máxima de 398 para 47 dias, entre março de 2026 e março de 2029 (Ballot SC-081v3). Pelo cronograma publicado pela DigiCert, o limite é de 200 dias para certificados emitidos a partir de 15 de março de 2026, 100 dias a partir de 15 de março de 2027 e 47 dias a partir de 15 de março de 2029 (DigiCert). Com prazos assim, renovação manual vira risco de site fora do ar por certificado vencido. Recomendação: automatizar a renovação e ter um alerta independente para o vencimento.

HSTS

O redirecionamento sozinho deixa uma brecha: a primeira requisição em http ainda trafega sem cifra. O cabeçalho Strict-Transport-Security (HSTS) diz ao navegador para usar só HTTPS naquele domínio pelo tempo definido em max-age, e o navegador passa a converter sozinho os links http e a impedir que o usuário ignore erros de certificado (MDN: Strict-Transport-Security). O ASVS pede no mínimo um ano de max-age (ASVS 5.0, requisito 3.4.1). Antes de incluir subdomínios ou pedir a entrada na lista de pré-carregamento dos navegadores, confira se todos os subdomínios funcionam em HTTPS; os detalhes estão no artigo sobre cabeçalhos HTTP de segurança.

Cabeçalhos de segurança, numa visão geral

Cabeçalhos de resposta HTTP dizem ao navegador o que ele pode fazer com a página: de onde carregar scripts, se a página pode ser exibida dentro de outra, que informação mandar a outros sites. Eles não corrigem falhas do código, mas reduzem o que um atacante consegue fazer com elas. A tabela resume os principais.

A Mozilla mantém guias práticos para cada item, em ordem sugerida de implantação pelo impacto e pela dificuldade, e o HTTP Observatory aponta para o guia de cada problema que encontra (MDN: guias práticos de segurança). O ASVS 5.0 também lista esses cabeçalhos entre os requisitos de front-end (ASVS 5.0, capítulo V3). Valores recomendados, exemplos e o que cada um pode quebrar estão no artigo sobre cabeçalhos HTTP de segurança.

Conteúdo misto

Conteúdo misto é quando uma página carregada em HTTPS pede recursos por HTTP. Esses recursos podem ser lidos ou alterados no caminho. Os navegadores atuais convertem para HTTPS imagens, áudio e vídeo pedidos por http e bloqueiam os demais tipos, como scripts, folhas de estilo, iframes, fontes e chamadas fetch() (MDN: conteúdo misto). Na prática, o sintoma mais comum é uma parte da página que some ou para de funcionar sem erro aparente.

Para achar, abra o console do navegador: os avisos de conteúdo misto aparecem lá. A correção é trocar os endereços para https ou para caminhos relativos. A diretiva upgrade-insecure-requests da CSP faz o navegador converter essas requisições para HTTPS, mas não substitui o HSTS e só funciona se o recurso existir em HTTPS (MDN: guia de CSP). Em CMS, os endereços em http costumam estar gravados no banco de dados, em posts antigos ou nas configurações do tema.

Arquivos expostos e listagem de diretório

Um site pode expor sem querer arquivos que não deveriam estar na pasta pública: cópias como login.php.old, arquivos .zip ou .tar.gz de backup, cópias automáticas de editores (como arquivo~), arquivos de configuração e pastas de controle de versão. O guia de testes da OWASP registra esse problema (WSTG-CONF-04) e explica o risco: uma cópia com extensão diferente pode ser entregue como texto, com o código-fonte e às vezes credenciais de banco de dados (OWASP WSTG, WSTG-CONF-04). O robots.txt não esconde esses arquivos: ele só pede aos robôs que não rastreiem um caminho, e qualquer pessoa pode lê-lo (RFC 9309).

O ASVS 5.0 tem requisitos diretos para isso (ASVS 5.0, seção V13.4):

• A aplicação vai para produção sem metadados de controle de versão, como as pastas .git e .svn, ou com essas pastas inacessíveis (13.4.1).

• O servidor não mostra listagem de diretório, a página automática com os arquivos de uma pasta, a menos que isso seja intencional (13.4.3).

• O servidor entrega só arquivos com extensões específicas, para não vazar configuração e código-fonte (13.4.7).

O arquivo .env merece atenção à parte: muitos frameworks usam esse nome para guardar senhas de banco, chaves de API e outros segredos em texto puro. Ele deve ficar fora da pasta pública. No seu próprio site, uma conferência rápida é pedir esses caminhos e ver o status:

for p in .env .git/HEAD backup.zip wp-config.php.bak; do
  printf '%s ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' "https://exemplo.com.br/$p"
done

O esperado é 403 ou 404. Atenção a sites que respondem 200 para qualquer endereço com uma página de erro própria: nesse caso, confira o conteúdo retornado, não só o status. A lista acima é um ponto de partida, não um inventário completo; o nome dos backups varia conforme o plugin ou o painel de hospedagem.

Versões de software, CMS e plugins

Componentes desatualizados continuam entre os riscos centrais da OWASP. No Top 10 de 2025, a categoria A03, falhas na cadeia de suprimentos de software, amplia a antiga categoria de componentes vulneráveis e desatualizados e inclui o caso de não acompanhar as versões de tudo o que se usa, no servidor e no navegador (OWASP Top 10:2025, A03). As recomendações incluem manter um inventário dos componentes, remover dependências e recursos sem uso, obter componentes só de fontes oficiais e aplicar correções conforme o risco, sem esperar um ciclo mensal ou trimestral.

Para um site em CMS, isso se traduz em atualizar núcleo, tema e plugins, apagar plugins desativados (código desativado continua no servidor) e acompanhar os avisos de segurança dos fornecedores. De fora, uma checagem só vê a versão que o site anuncia, em cabeçalhos como Server e X-Powered-By ou em meta tags do HTML. A OWASP recomenda remover esses cabeçalhos (OWASP Secure Headers Project, lista de cabeçalhos a remover), e o ASVS lembra que esconder a versão não elimina a necessidade de atualizar (ASVS 5.0, seção V13.4). Em outras palavras, não ver a versão de fora não quer dizer que ela está em dia.

Scripts de terceiros como risco de cadeia de suprimentos

Cada script carregado de outro domínio (chat, analytics, pixel de anúncio, gerenciador de tags, widget de avaliação) roda com as mesmas permissões dos scripts do próprio site. Se o fornecedor for comprometido ou trocar o arquivo, o código novo roda na sua página sem nenhuma mudança no seu servidor. O PCI DSS descreve esse risco na orientação do requisito 6.4.3: scripts aparentemente inofensivos podem ser usados para carregar código malicioso que lê e envia para fora os dados do cartão (PCI DSS v4.0.1, requisito 6.4.3).

As medidas básicas são três. A primeira é ter um inventário: quais scripts cada página carrega, de onde e por quê. A segunda é verificar a integridade quando possível: o atributo integrity (SRI, Subresource Integrity) faz o navegador recusar um arquivo cujo conteúdo não bate com o hash declarado, e o ASVS pede SRI para recursos estáticos e versionados hospedados fora (ASVS 5.0, requisito 3.6.1; MDN: SRI). A terceira é limitar as origens com uma CSP. SRI não serve para scripts que o fornecedor atualiza sem mudar o endereço, e é aí que entram inventário e monitoramento. Em páginas de pagamento isso deixou de ser só boa prática: veja o artigo sobre os requisitos 6.4.3 e 11.6.1 do PCI DSS. Os mesmos scripts também levam dados de visitantes para terceiros, o que entra na LGPD, tema do artigo sobre pixels e scripts de terceiros.

Formulários e cookies

Formulários de contato, login e checkout devem ser servidos e enviados em HTTPS. Um formulário numa página HTTPS que envia para um endereço http expõe os dados no envio.

Cookies de sessão e de login pedem três atributos (MDN: Set-Cookie):

Sem SameSite, alguns navegadores aplicam Lax por padrão, de forma um pouco mais permissiva que o Lax explícito (MDN: Set-Cookie; web.dev: SameSite cookies explained). O mais seguro é declarar o valor. O ASVS 5.0 vai além e pede os prefixos __Host- ou __Secure- no nome dos cookies, que fazem o navegador rejeitar o cookie se ele não tiver Secure e, no caso de __Host-, se tiver atributo Domain ou caminho diferente de / (ASVS 5.0, requisitos 3.3.1 a 3.3.4).

Para conferir, abra o painel de cookies do DevTools (aba Application no Chrome) depois de fazer login e veja as colunas Secure, HttpOnly e SameSite de cada cookie. Cookies de ferramentas de terceiros são gravados por elas, e nem sempre dá para mudar seus atributos.

Por onde começar

Uma ordem prática, do mais simples e com mais efeito para o mais trabalhoso, inspirada na sequência dos guias da Mozilla (MDN: guias práticos de segurança). É uma recomendação, não uma regra; um e-commerce com checkout próprio deve antecipar o passo dos scripts.

1. Servir todas as páginas em HTTPS, com redirecionamento de http para https no mesmo host.

2. Desligar TLS 1.0 e 1.1 e automatizar a renovação do certificado, com alerta de vencimento.

3. Procurar e remover arquivos expostos (.env, .git, backups) e desligar a listagem de diretório.

4. Atualizar CMS, tema e plugins e apagar o que não é usado.

5. Corrigir conteúdo misto e ativar o HSTS, primeiro com max-age curto.

6. Revisar os atributos dos cookies de sessão.

7. Adicionar os cabeçalhos simples (nosniff, Referrer-Policy, frame-ancestors) e começar a CSP em modo de relatório.

8. Fazer o inventário dos scripts de terceiros e cortar os que não têm motivo para estar ali.

Como verificar o seu site

Para cabeçalhos e redirecionamento, o HTTP Observatory da Mozilla é gratuito e explica cada item. No WebVyze, o verificador de redirecionamentos, gratuito, mostra a cadeia de saltos de uma URL; teste com o endereço em http:// para ver se o primeiro salto vai para HTTPS no mesmo host. A auditoria do WebVyze, que o plano grátis roda uma vez a cada 30 dias, checa HTTPS, validade do certificado TLS, HSTS, se a página pode ser embutida por outros sites, a presença e o efeito da CSP, os atributos Secure, HttpOnly e SameSite dos cookies, o atributo integrity em bibliotecas de CDN pública, X-Content-Type-Options, Referrer-Policy, versão de software exposta pelo servidor e plugins ou temas com vulnerabilidades conhecidas. Para lojas, os planos pagos mantêm um inventário dos scripts das páginas de checkout, ligado aos requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0. O WebVyze só lê páginas públicas e nunca altera o site, então ele enxerga o que está na tabela da primeira seção e nada além disso. Nenhuma dessas ferramentas substitui um teste de intrusão ou a revisão do código.