Como verificar a segurança do seu site sem invadir nada

Verificações passivas de segurança para lojas virtuais: certificado TLS, HSTS, CSP, nosniff, cookies, conteúdo misto, jQuery antigo, security.txt e DMARC.

Equipe editorial FixReports12 min de leitura

Você consegue verificar boa parte da configuração de segurança de uma loja virtual pelo lado de fora, lendo o que o site já envia a todo visitante: o certificado TLS, os redirecionamentos, os cabeçalhos de resposta HTTP, os cookies, os scripts que ele carrega e os registros DNS públicos. Essas verificações passivas não enviam tráfego de ataque nem exigem login, por isso não colocam na loja mais carga do que uma visita normal. Elas encontram falhas de configuração, como um certificado prestes a vencer, falta de HSTS, cookies inseguros, conteúdo misto ou uma versão do jQuery com falhas conhecidas. Elas não são um teste de invasão (pentest) e não conseguem provar que uma loja é segura.

Pontos principais

  • Os certificados TLS publicamente confiáveis emitidos desde 15 de março de 2026 podem ter validade de no máximo 200 dias, limite que cai para 100 dias em março de 2027 e para 47 dias em março de 2029 (CA/Browser Forum (abre em uma nova aba)).
  • Os navegadores ignoram o cabeçalho HSTS quando ele é enviado por HTTP sem criptografia (MDN (abre em uma nova aba)).
  • A diretiva frame-ancestors da CSP não funciona em uma tag <meta>; ela precisa ser enviada como cabeçalho de resposta (MDN (abre em uma nova aba)).
  • As versões do jQuery anteriores à 3.5.0 são afetadas por duas vulnerabilidades de XSS, e a CISA incluiu uma delas, a CVE-2020-11023, no seu catálogo Known Exploited Vulnerabilities em 23 de janeiro de 2025 (NVD (abre em uma nova aba)).
  • Um arquivo security.txt precisa ter os campos Contact e Expires e ficar em /.well-known/security.txt (RFC 9116 (abre em uma nova aba)).

O que conta como verificação de segurança passiva?

Uma verificação passiva só lê o que o site ou o DNS dele devolvem a uma requisição comum.

Isso significa carregar páginas públicas, ler o certificado e os cabeçalhos de resposta, listar os cookies e os scripts que uma página define e consultar registros DNS públicos. Uma verificação passiva não tenta adivinhar senhas, não envia payloads de injeção, não sonda URLs de administração e não faz varredura de portas. Tudo o que vem a seguir pode ser feito com um navegador, curl, openssl e dig.

Como verificar o certificado TLS e a validade dele?

Leia diretamente as datas e os nomes do certificado e garanta que a renovação seja automática.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Confira se o notAfter está bem distante no futuro, se o certificado cobre tanto example.com quanto www.example.com, caso você use os dois (o visualizador de certificados do navegador lista os nomes), e se o navegador não mostra nenhum alerta. A validade dos certificados está diminuindo conforme os Baseline Requirements do CA/Browser Forum (seção 6.3.2, versão 2.3.1 em outubro de 2026), após a Ballot SC-081v3 (abre em uma nova aba), aprovada em 11 de abril de 2025:

Certificado emitidoValidade máxima
Antes de 15 de março de 2026398 dias
De 15 de março de 2026 a 14 de março de 2027200 dias
De 15 de março de 2027 a 14 de março de 2029100 dias
A partir de 15 de março de 202947 dias

Prazos de validade curtos tornam a renovação manual arriscada, então confirme que a sua hospedagem ou a sua ferramenta de certificados faz a renovação automaticamente. Confirme também que o HTTP sem criptografia redireciona para HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

O esperado é uma resposta 301 (ou 308) com um cabeçalho location que comece com https://.

Quais cabeçalhos de segurança uma loja virtual deve enviar?

Um pequeno conjunto de cabeçalhos de resposta bloqueia ataques comuns no navegador a um custo quase nulo.

CabeçalhoO que fazValor típicoFonte
Strict-Transport-SecurityDiz aos navegadores para usar só HTTPS e impede que os usuários ignorem erros de certificadomax-age=31536000; includeSubDomainsMDN (abre em uma nova aba)
Content-Security-Policy: frame-ancestorsControla quais sites podem incorporar as suas páginas, o que protege contra clickjackingframe-ancestors 'self'MDN (abre em uma nova aba)
X-Frame-OptionsControle de enquadramento mais antigo; a OWASP diz que o frame-ancestors o torna obsoleto nos navegadores compatíveisDENY ou SAMEORIGINOWASP (abre em uma nova aba)
X-Content-Type-OptionsImpede o MIME sniffing e bloqueia scripts e folhas de estilo servidos com o tipo erradonosniffMDN (abre em uma nova aba)
Referrer-PolicyLimita quanto das suas URLs é enviado a outros sitesstrict-origin-when-cross-originOWASP
X-XSS-ProtectionCabeçalho do filtro de XSS do navegador; a OWASP diz que ele pode criar vulnerabilidades de XSS em sites que, sem ele, seriam segurosNão defina, ou use 0OWASP

Veja o que a sua loja envia:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Dois cuidados. O includeSubDomains bloqueia qualquer subdomínio que só funcione por HTTP, então verifique os subdomínios antes. O preload do HSTS exige max-age de pelo menos 31536000 e includeSubDomains, então só adicione preload quando todos os subdomínios estiverem prontos para HTTPS. Uma CSP completa que restrinja os scripts vale a pena, mas a OWASP observa que ela é complexa de configurar e de manter, e lojas com muitos apps precisam testá-la com cuidado.

Seus cookies usam Secure, HttpOnly e SameSite?

Os cookies de sessão e de carrinho devem ter os três atributos, e você pode vê-los nos cabeçalhos de resposta Set-Cookie.

AtributoEfeito (segundo o MDN (abre em uma nova aba))Onde importa
SecureEnviado só por HTTPS; sites em HTTP sem criptografia não conseguem defini-loTodos os cookies de uma loja em HTTPS
HttpOnlyO JavaScript não consegue lê-lo por document.cookie, o que ajuda contra XSSSessões de login e carrinhos
SameSite=Lax ou StrictLimita quando o cookie é enviado em requisições entre sitesSessões; Strict é adequado para cookies de autenticação e de carrinho
SameSite=NoneEnviado em requisições entre sites; precisa ser combinado com SecureSó recursos incorporados de terceiros que precisem dele

Se nenhum atributo SameSite for definido, os navegadores tratam o cookie como Lax. Os cookies que os seus próprios scripts precisam ler não podem ser HttpOnly, então concentre-se nos que identificam um cliente logado ou um administrador.

curl -sI https://example.com/ | grep -i "^set-cookie"

As ferramentas de desenvolvedor do navegador mostram as mesmas informações, incluindo os cookies definidos por scripts depois que a página carrega.

Como encontrar conteúdo misto?

Conteúdo misto é qualquer recurso carregado por HTTP em uma página servida por HTTPS, e o console do navegador lista esses recursos.

O MDN (abre em uma nova aba) divide o conteúdo misto em dois grupos. Imagens, áudio e vídeo são “atualizáveis” (upgradable): os navegadores os solicitam automaticamente por HTTPS. Scripts, folhas de estilo, iframes, fontes e requisições fetch() são “bloqueáveis” (blockable): os navegadores os bloqueiam, o que quebra tudo o que dependia deles. As requisições atualizadas para um endereço IP puro, sem nome de domínio, também são bloqueadas.

Para encontrá-lo, abra o console nos seus templates principais (página inicial, coleção, produto, carrinho) e procure http:// no código do tema, no conteúdo das páginas e nas configurações dos apps. A Central de Ajuda da Shopify diz que qualquer página da loja com um recurso que não seja entregue por HTTPS é considerada insegura (abre em uma nova aba) e recomenda hospedar os recursos na Shopify ou servi-los por HTTPS. No WooCommerce, verifique o conteúdo de posts antigos e as opções do tema se o site já funcionou em http://.

Como identificar bibliotecas JavaScript desatualizadas com CVEs conhecidas?

Liste as bibliotecas que cada página carrega, leia as versões delas e compare-as com a National Vulnerability Database (NVD).

Comece pelo jQuery. No console do navegador, $.fn.jquery retorna a versão carregada (API do jQuery (abre em uma nova aba)). Versões que merecem alerta:

CVEVersões afetadasProblemaPontuação na NVD (v3.1)
CVE-2020-11022 (abre em uma nova aba)Da 1.12.0 até antes da 3.5.0Passar HTML não confiável a métodos como .html() ou .append() pode executar código6,1 (média)
CVE-2020-11023 (abre em uma nova aba)Da 1.0.3 até antes da 3.5.0O mesmo, para HTML que contém elementos <option>; no catálogo KEV da CISA desde 23 de janeiro de 20256,1 (média)
CVE-2019-11358 (abre em uma nova aba)Antes da 3.4.0Poluição de protótipo (prototype pollution) por meio de jQuery.extend(true, ...)6,1 (média)

Os dois problemas de 2020 foram corrigidos no jQuery 3.5.0. Uma versão vulnerável significa que o código com a falha está presente; se ela pode ser explorada depende de como o site passa dados para esse código. O WordPress inclui o jQuery 3.5.1 desde a versão 5.6 (abre em uma nova aba), então um jQuery antigo em uma loja WooCommerce indica um WordPress desatualizado ou um tema ou plugin que carrega a própria cópia. Na Shopify, verifique os arquivos do tema e os apps que injetam scripts.

O que é o security.txt e a sua loja precisa de um?

É um arquivo de texto simples que diz aos pesquisadores de segurança como relatar uma vulnerabilidade a você.

A RFC 9116 (abre em uma nova aba) (abril de 2022, uma RFC informativa, então segui-la é voluntário) diz que o arquivo deve ser servido por HTTPS em /.well-known/security.txt como text/plain. Contact e Expires são obrigatórios, e a RFC recomenda uma data em Expires a menos de um ano no futuro.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

No WooCommerce, você pode colocar o arquivo no seu servidor. Em uma plataforma hospedada, verifique se é possível publicar um arquivo nesse caminho; se não for, um contato de segurança bem identificado na sua página de contato já ajuda.

Como o DMARC protege a sua loja contra falsificação de e-mail?

O DMARC permite pedir aos provedores de e-mail que coloquem em quarentena ou rejeitem as mensagens que usam o seu domínio no endereço do remetente (From) sem passar em SPF ou DKIM alinhados.

Um registro com p=none só coleta relatórios; ele não impede e-mails falsificados. Os clientes esperam receber confirmações de pedido e redefinições de senha do seu domínio, então vale a pena bloquear uma mensagem de phishing que exiba exatamente o seu domínio. Verifique a sua política com dig +short TXT _dmarc.example.com e consulte a RFC 9989 (abre em uma nova aba) para ver a especificação. O DMARC não cobre domínios parecidos, só o domínio que publica o registro.

O que a Shopify gerencia e o que você controla no WooCommerce?

A Shopify opera os servidores por trás das vitrines das lojas, enquanto uma loja WooCommerce auto-hospedada deixa as configurações do servidor com você e com a sua hospedagem.

VerificaçãoShopifyWooCommerce (auto-hospedado)
Certificado TLSGratuito para todos os domínios adicionados à Shopify (abre em uma nova aba); pode levar até 48 horas para domínios de terceirosSua hospedagem ou a sua própria configuração
Redirecionamento de HTTP para HTTPSPlataformaConfigurações do servidor web, da CDN ou da hospedagem
Cabeçalhos de segurançaEnviados pelos servidores da ShopifyServidor web, CDN ou um plugin
Flags de cookiesOs cookies da própria Shopify são definidos pela plataforma; os cookies de apps e do tema são responsabilidade suaNúcleo do WordPress, plugins e servidor
Conteúdo misto e bibliotecas JSSeu tema, conteúdo e appsSeu tema, conteúdo e plugins
security.txt e DMARCSeu domínio e DNSSeu domínio e DNS

Quando verificamos várias vitrines hospedadas na Shopify em outubro de 2026, as respostas incluíam HSTS com max-age de cerca de 91 dias, X-Content-Type-Options: nosniff e uma CSP com upgrade-insecure-requests, enquanto o frame-ancestors variava de uma loja para outra. A Shopify diz que tem certificação de conformidade com o PCI DSS Nível 1 (abre em uma nova aba). O seu tema e os apps instalados continuam sendo responsabilidade sua.

No WooCommerce, o guia de proteção (hardening) (abre em uma nova aba) do WordPress recomenda manter o WordPress e os plugins atualizados, excluir os plugins que você não usa e perguntar à sua hospedagem quais precauções de segurança ela adota.

Por que isso não é um teste de invasão?

Um teste de invasão tenta ataques de forma ativa; as verificações passivas só observam.

A NIST SP 800-115 define o teste de invasão como um teste de segurança em que os avaliadores imitam ataques reais para encontrar formas de contornar os recursos de segurança de um sistema (glossário do NIST (abre em uma nova aba)). As verificações passivas não enxergam falhas no lado do servidor em plugins, senhas de administrador fracas ou reutilizadas, falta de autenticação em dois fatores, falhas de controle de acesso nem código vulnerável que nunca aparece no código-fonte da página. Use essas verificações como uma linha de base que você pode repetir a qualquer momento. Para uma garantia mais profunda, contrate um teste de invasão com escopo por escrito, em sistemas que sejam seus ou que você tenha autorização para testar.

Uma análise gratuita faz uma primeira passada pela sua loja. O Relatório de Segurança do Site cobre as verificações passivas deste artigo, do TLS e dos redirecionamentos aos cabeçalhos, cookies, conteúdo misto, bibliotecas desatualizadas, security.txt e DMARC, com correções para cada problema encontrado. Como qualquer análise passiva, ele não pode garantir que uma loja esteja segura.

Perguntas frequentes

As verificações de segurança passivas colocam a minha loja em risco?

Não mais do que uma visita normal. Elas solicitam as mesmas páginas públicas e os mesmos registros DNS que qualquer navegador ou servidor de e-mail solicitaria, e não tentam fazer login nem enviar payloads de ataque.

Posso adicionar cabeçalhos de segurança na Shopify?

Os cabeçalhos de resposta da vitrine vêm dos servidores da Shopify, então entre em contato com o Suporte da Shopify se faltar algum de que você precise. Uma tag <meta> de CSP no seu tema pode adicionar algumas diretivas, mas o MDN observa que o frame-ancestors não é aceito em <meta>.

Uma versão antiga do jQuery significa que a minha loja foi invadida?

Não. Significa que um código com vulnerabilidades conhecidas está sendo carregado, o que aumenta o risco se o site passar HTML não confiável aos métodos afetados. Atualize o jQuery ou remova o tema ou plugin que o carrega.

Por quanto tempo um certificado TLS pode ser válido agora?

Os certificados publicamente confiáveis emitidos a partir de 15 de março de 2026 podem ter validade de no máximo 200 dias. O limite cai para 100 dias a partir de 15 de março de 2027 e para 47 dias a partir de 15 de março de 2029.

O arquivo security.txt é obrigatório?

A RFC 9116 é uma RFC informativa, então publicar o arquivo é voluntário segundo o padrão. Ele é barato de publicar e dá aos pesquisadores uma forma clara de entrar em contato com você.

Uma análise passiva sem problemas significa que a minha loja é segura?

Não. Ela mostra que a configuração pública parece correta. Vulnerabilidades no servidor, segurança das contas e falhas na lógica de negócio precisam de outros testes.

Fontes

Todos os guias