Checklist de lançamento de site: 8 verificações de segurança antes de colocar no ar

1. O checklist de lançamento numa tabela

Verifique cada nome público em que o site responde, normalmente o domínio sem www e o www, tanto por http:// quanto por https://. Antes da troca de DNS, dá para testar o servidor novo com o nome real usando curl -sI --resolve example.com:443:203.0.113.10 https://example.com/, com o IP do servidor novo no lugar do IP de exemplo.

As oito linhas seguem as oito verificações passivas do snapshot gratuito de prontidão para lançamento, que analisa uma origem pública sem conta. Os passos manuais abaixo vão além do que uma única passada numa origem consegue: cobrem todos os nomes de host, os dois protocolos, as páginas de erro, o DKIM e as configurações no registrador.

2. Resolução de DNS: todos os nomes apontam para o host novo

Por que importa. Uma migração pela metade passa despercebida com facilidade: o domínio sem www já está no servidor novo, enquanto o www continua como CNAME para a plataforma antiga. Registros que sobraram também são um problema de segurança. A cheat sheet da OWASP sobre sequestro de subdomínio (subdomain takeover) explica como um CNAME apontando para um recurso de nuvem apagado pode deixar outra pessoa assumir o subdomínio, e como um registro MX esquecido pode permitir que um atacante receba e-mails desse nome e até obtenha certificados por validação via e-mail.

Como conferir.

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
dig +short NS example.com

Repita as consultas num resolvedor público (dig @1.1.1.1 …), caso a sua rede guarde uma resposta em cache, e depois revise a exportação completa da zona no seu provedor de DNS.

Como é um bom resultado. Todo nome público resolve para o host esperado, registros AAAA só existem se o host realmente serve o site por IPv6, pelo menos dois servidores de nomes respondem (o mínimo que a RFC 1034 define) e cada registro tem finalidade e responsável conhecidos.

Correção típica. Reaponte ou apague os registros obsoletos. Ao desativar um serviço, siga a ordem que a OWASP recomenda: atualize ou remova o registro DNS, espere pelo menos um TTL e só então apague o recurso na nuvem. Antes de uma virada, reduza o TTL com antecedência suficiente para que o TTL antigo, mais longo, já tenha expirado na hora da troca, e volte a aumentá-lo quando a mudança estiver estável.

3. SPF, DMARC e CAA: os registros que falam pelo seu domínio

Por que importa. Qualquer pessoa pode colocar o seu domínio no campo From de um e-mail. O SPF lista os servidores autorizados a enviar e-mail por ele, o DKIM assina as mensagens e o DMARC diz aos destinatários o que fazer quando nem o SPF nem o DKIM passam alinhados com o domínio visível no From. Gmail, Yahoo e Outlook.com exigem os três de remetentes em massa. O CAA indica as autoridades certificadoras autorizadas a emitir certificados para os seus nomes, e as CAs públicas precisam consultá-lo antes de emitir.

Como conferir. Consulte o domínio usado nos seus endereços de From, normalmente o domínio registrado, e não o www:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CAA example.com

Como é um bom resultado.

• SPF: exatamente um registro v=spf1, dentro do limite da RFC 7208 de 10 termos que geram consultas DNS (includes aninhados contam), terminando em ~all ou -all, nunca +all.
• DMARC: um registro como v=DMARC1; p=none; rua=mailto:dmarc@example.com, para que os relatórios cheguem antes de você apertar a política. O padrão atual, a RFC 9989 (maio de 2026), diz que domínios cujos usuários possam enviar mensagens a listas de discussão não deveriam publicar p=reject; os que ainda quiserem devem passar antes pelo menos um mês em p=none e o mesmo tempo em quarantine, comparando os relatórios.
• DKIM: todo serviço que envia por você assina com o seu domínio. As chaves públicas ficam em seletor._domainkey.example.com, então você precisa de cada seletor para consultá-las; ele aparece na tag s= do cabeçalho DKIM-Signature de uma mensagem enviada pelo serviço.
• CAA: um registro como 0 issue "letsencrypt.org" para cada CA que você usa, incluindo a da sua CDN. Não ter registro CAA é permitido, e o CAA não impede que uma CA autorizada emita por engano.

Correção típica. Junte registros SPF duplicados, remova os includes de serviços desativados e comece o DMARC em p=none com relatórios. Um hard fail não é automaticamente mais seguro: a RFC 9989 alerta que, com -all, um e-mail pode ser rejeitado pelo resultado do SPF antes de o DMARC rodar, mesmo quando uma assinatura DKIM alinhada o aprovaria, e essas rejeições nunca aparecem nos relatórios DMARC. Destinatários que não encontram registro DMARC num subdomínio sobem pela árvore do DNS até a política do domínio pai, e uma CA usa o registro CAA mais próximo, no nome para o qual está emitindo ou acima dele, como explica a página do Let's Encrypt sobre CAA. Por isso, a falta de _dmarc ou de CAA no www não é, por si só, uma falha. O guia para verificar SPF e DMARC mostra como ler e corrigir esses registros.

4. Certificado TLS: válido, compatível com os nomes e renovado por alguém

Por que importa. Com um certificado vencido ou que não corresponde ao nome, o visitante esbarra num aviso do navegador, e num host que usa HSTS não dá para ignorar esse aviso. As renovações também estão ficando mais frequentes: pela votação SC081v3 do CA/Browser Forum, certificados publicamente confiáveis emitidos desde 15 de março de 2026 valem no máximo 200 dias, prazo que cai para 100 dias a partir de março de 2027 e para 47 dias a partir de março de 2029. O Let's Encrypt parou de enviar e-mails de aviso de expiração em 4 de junho de 2025.

Como conferir. Para cada nome de host:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -ext subjectAltName

Rode também o s_client sozinho: a saída deve incluir Verify return code: 0 (ok) e mostrar o protocolo negociado.

Como é um bom resultado. A cadeia é validada com os certificados intermediários que o servidor envia, o certificado cobre todos os nomes que você atende, a conexão usa TLS 1.3 ou 1.2, a renovação é automática e a documentação de operação diz quem é o responsável. Existe um alerta de expiração que não depende da autoridade certificadora.

Correção típica. Automatize a renovação com ACME. O Let's Encrypt recomenda o ACME Renewal Information (ARI) ou renovar mais ou menos aos dois terços da validade do certificado, e alerta que um intervalo fixo de 60 dias não vai bastar quando os certificados durarem 45 dias. Depois de uma migração, confirme que a plataforma nova realmente renova; se o certificado foi ativado pelo painel da hospedagem, confira se a renovação é automática e se ele cobre o www e o domínio sem www. Um handshake mostra só o protocolo negociado; por isso, use um scanner que liste todas as versões suportadas para confirmar que TLS 1.0 e 1.1 estão desligados.

Como o certificado, o HSTS e as demais proteções do navegador se combinam em uma visita por HTTPS está explicado no guia do certificado SSL/TLS e do HTTPS.

5. Redirecionamento HTTPS: um salto para HTTPS, um host canônico e depois HSTS

Por que importa. Links antigos, favoritos, scripts e clientes mais velhos ainda pedem endereços http://. Um redirecionamento os leva ao HTTPS, mas, como aponta o hstspreload.org, um atacante posicionado no caminho da conexão pode interceptar e reescrever esse redirecionamento. O HSTS fecha essa brecha em todas as visitas depois da primeira visita segura.

Como conferir.

curl -sI http://example.com/
curl -sI http://www.example.com/
curl -sIL "http://example.com/page?x=1" | grep -iE '^(HTTP|location)'

Como é um bom resultado.

• Um redirecionamento permanente (301, ou 308 para manter o método da requisição) para o mesmo caminho em HTTPS no mesmo host, como recomenda o guia de TLS do MDN, e depois no máximo mais um salto para o host canônico. O caminho e a query string são preservados.
• A resposta HTTPS envia Strict-Transport-Security. Os navegadores ignoram o cabeçalho em HTTP simples, então o redirecionamento em si não precisa dele.
• Nada de conteúdo misto: os navegadores bloqueiam scripts carregados por http:// em páginas HTTPS.

Correção típica. Redirecione no servidor ou na CDN, não em JavaScript. Aumente o max-age do HSTS por etapas até um valor longo como 31536000 (um ano) e só acrescente includeSubDomains quando todos os subdomínios servirem HTTPS. O hstspreload.org agora recomenda o HSTS, mas não o preload. Se os certificados usam o desafio ACME HTTP-01, mantenha a porta 80 acessível. Para testar este item com o snapshot gratuito, digite o endereço http://; com um domínio sem protocolo ou um endereço https://, ele verifica o max-age do HSTS e o conteúdo misto no lugar do redirecionamento.

6. Cabeçalhos de segurança: confira a resposta final e as páginas de erro

Por que importa. Os cabeçalhos de segurança dizem ao navegador o que uma página pode carregar, quem pode colocá-la num frame e como tratar os tipos de conteúdo. Eles costumam ficar na configuração do servidor ou da CDN, então uma troca de hospedagem pode fazê-los sumir. Eles limitam o estrago de falhas como cross-site scripting; não corrigem as falhas.

Como conferir.

curl -sIL https://example.com/
curl -sI https://example.com/no-such-page

Confira também a página de erro: sem o parâmetro always, o nginx só envia os valores de add_header com determinados códigos de status, como observa a OWASP HTTP Headers Cheat Sheet.

Como é um bom resultado. Um conjunto inicial razoável para um site simples:

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

• Implante a CSP primeiro como Content-Security-Policy-Report-Only. Ela precisa permitir tudo o que as suas páginas carregam de forma legítima, e 'unsafe-inline' anula boa parte do objetivo dela.
• frame-ancestors não herda de default-src e é ignorado numa tag <meta>; X-Frame-Options: DENY é a alternativa mais antiga.
• Os cookies de sessão têm Secure, HttpOnly e um SameSite explícito (veja o MDN sobre Set-Cookie). O HttpOnly impede que scripts da página leiam o cookie (por exemplo, via document.cookie), mas o navegador continua enviando-o nas requisições correspondentes; assim, ele limita o roubo de cookies por XSS sem impedir o XSS em si.
• Nenhum cabeçalho X-XSS-Protection, ou com valor 0.

Correção típica. Defina os cabeçalhos numa única camada (servidor, aplicação ou CDN), para que toda resposta, inclusive as de erro, receba cada cabeçalho exatamente uma vez. O guia para verificar cabeçalhos de segurança explica cada cabeçalho em detalhe, com exemplos para nginx, para o .htaccess do Apache e para hospedagens estáticas.

7. Exposição de tecnologia, cache e compressão

Exposição de tecnologia

Por que importa. Server, X-Powered-By e a metatag generator contam a qualquer um qual software você usa, e o MDN observa que números de versão detalhados podem facilitar a busca por vulnerabilidades conhecidas. Escondê-los é higiene, não proteção: o guia de testes da OWASP chama isso de segurança por obscuridade, e o MDN diz que manter tudo atualizado é a abordagem mais robusta.

Como conferir. Rode curl -sI https://example.com/ | grep -iE '^(server|x-powered-by):' e depois procure no código-fonte da página por generator e por nomes de arquivos de script que tragam números de versão.

Como é um bom resultado. Server: nginx sem número de versão, e nenhum X-Powered-By.

Correção típica. server_tokens off; no nginx, expose_php = Off no php.ini, app.disable('x-powered-by') no Express. Se uma página revela uma biblioteca desatualizada, atualize-a em vez de escondê-la.

Cache, compressão e CDN

Por que importa. As regras de cache decidem quem recebe uma cópia armazenada de uma resposta. Uma página pessoal guardada em cache por uma CDN pode ser entregue ao próximo visitante; é por isso que o MDN diz que respostas personalizadas precisam de Cache-Control: private.

Como conferir. Rode curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/, depois faça login, abra uma página da conta (como “Meus pedidos” numa loja virtual) e leia os cabeçalhos de resposta nas ferramentas de desenvolvedor do navegador.

Como é um bom resultado. HTML servido com Content-Encoding: br ou gzip; um Cache-Control explícito em toda resposta; um max-age longo mais immutable só em arquivos estáticos versionados; private ou no-store nas páginas com dados do usuário (no-cache ainda permite armazenar).

Correção típica. Defina o Cache-Control por tipo de rota, mantenha os caminhos com login fora do cache da CDN e comprima texto no servidor ou na CDN. Não ter CDN não é um risco por si só; o guia de teste de velocidade do site trata do desempenho.

8. Registro do domínio: expiração, bloqueio e contatos

Por que importa. Quando expira um domínio sob um domínio de topo genérico (gTLD), como .com, a Expired Registration Recovery Policy da ICANN exige que o registrador interrompa a resolução de DNS dele por um período, e o site e o e-mail param juntos. Os avisos de renovação vão para o contato cadastrado, que pode ser um ex-funcionário ou uma caixa de e-mail no próprio domínio que está vencendo.

Como conferir. Para domínios genéricos, use a ferramenta de consulta da ICANN. Desde 28 de janeiro de 2025, o RDAP é a fonte oficial dos dados de registro dos domínios genéricos; o WHOIS continua obrigatório só para .com, .name e .post. Para domínios de código de país (ccTLDs), use a consulta do próprio registro ou do registrador. No caso do .br (como .com.br), a ficha do .br na IANA aponta o Comitê Gestor da Internet no Brasil como responsável, o Registro.br como serviço de registro, o servidor RDAP rdap.registro.br e o WHOIS whois.registro.br. A política da ICANN citada acima vale para domínios genéricos; para o .br, valem as regras do Registro.br. Em seguida, entre na conta onde o domínio é administrado e confira as configurações.

Como é um bom resultado.

• Vencimento só daqui a alguns meses, renovação automática ativa e uma forma de pagamento que ainda vai valer na data da renovação.
• Em domínios genéricos, clientTransferProhibited ativo, além dos bloqueios de atualização e exclusão onde o registrador os oferecer; nenhum clientHold ou serverHold, que tiram o domínio do DNS.
• Contatos que chegam a mais de uma pessoa, com pelo menos um endereço fora do próprio domínio, e login com múltiplos fatores na conta do registrador.

Correção típica. Ative a renovação automática, renove por vários anos, peça ao registrador que ative os status de bloqueio (o guia de códigos de status EPP da ICANN explica cada um) e atualize os contatos.

9. O que este checklist não cobre

Estes oito itens descrevem a configuração pública em volta do seu site. Um site pode passar em todos e ainda assim ser fácil de invadir, porque nenhum deles olha a aplicação ou a forma como ela é operada. Revise separadamente:

• Vulnerabilidades da aplicação: injeção, cross-site scripting nos seus templates, uploads inseguros, acesso entre contas.
• Autenticação e sessões: login, redefinição de senha, autenticação multifator, painéis de administração.
• Dependências e servidores: plugins do CMS, pacotes, atualizações do sistema operacional.
• Segredos e acessos: chaves em repositórios ou em bundles do front-end, e quem tem acesso à produção, ao provedor de DNS e ao registrador.
• Backups: uma restauração que você realmente testou.

O guia de auditoria de segurança de site percorre login, permissões e outras verificações do lado da aplicação, e o OWASP Web Security Testing Guide traz casos de teste detalhados.

Uma primeira passada rápida numa origem. O snapshot gratuito de prontidão para lançamento não pede conta. Para uma origem pública, ele lê o DNS público, os registros DNS de e-mail, os dados de registro do domínio, o handshake TLS e a resposta HTTP da página inicial, e não envia exploits, varreduras de portas, tentativas de login nem testes de carga. Você recebe uma pontuação, uma nota de blindagem, a contagem de sinais de risco e de verificações aprovadas e até três sinais para olhar primeiro. Ele não é um pentest: uma boa pontuação significa que esses sinais públicos pareciam saudáveis naquele momento. O plano Free cobre só as verificações de segurança; as seis áreas de auditoria (segurança, SEO técnico, visibilidade em IA, acessibilidade, desempenho e integrações) começam no plano Starter, a partir de US$ 49 por mês.