Neste artigo
Superfície de ataque: o que muda no site estático
Superfície de ataque é o conjunto de pontos por onde alguém pode tentar entrar. Cada login, plugin, formulário e serviço conectado é um ponto. Quanto menos pontos, menos coisas você precisa atualizar e vigiar.
Um site estático é feito de arquivos prontos entregues ao navegador. Nada roda no servidor na hora da visita. Para entender essa arquitetura, veja o que são sites estáticos.
| Ponto de entrada | Site com sistema de gestão | Site em HTML puro |
|---|---|---|
| Painel de login no próprio domínio | Sim, em endereço conhecido | Não existe |
| Plugins e temas de terceiros | Sim, cada um com atualização própria | Não existe |
| Banco de dados | Sim | Não existe, se o site não usar |
| Código rodando no servidor a cada visita | Sim | Não |
| Contas de publicação (GitHub, Cloudflare, hospedagem) | Sim | Sim, e viram o ponto principal |
| Formulários e integrações | Depende do site | Depende do site |
| Domínio e DNS | Sim | Sim |
A tabela mostra o essencial: o estático corta as três primeiras linhas, mas as quatro últimas continuam valendo. Se o seu site já é WordPress, as dicas de segurança de site WordPress cobrem atualização, plugins e limpeza de vírus.
O que a OWASP ensina sobre isso
A OWASP (Open Web Application Security Project) é uma comunidade sem fins lucrativos que publica de graça materiais sobre segurança de aplicações web. Segundo a Wikipédia, ela começou em 2001. O documento mais conhecido é o OWASP Top 10, uma lista de conscientização sobre as falhas mais importantes.
A versão de 2017, listada na Wikipédia, inclui injeção de código, quebra de autenticação, configuração incorreta de segurança, XSS (Cross-Site Scripting) e uso de componentes com vulnerabilidades conhecidas. Repare: boa parte dessas categorias dependem de código rodando no servidor, de login ou de componentes de terceiros.
Um site só com HTML e CSS não tem login para quebrar nem banco para receber injeção. Já XSS, configuração incorreta e componentes vulneráveis podem aparecer em qualquer site, inclusive no estático. É aí que você precisa agir.
O que continua exigindo cuidado
O site estático não elimina o risco, ele concentra o risco em poucos lugares. Estes são os 5 que mais importam.
- Conta do GitHub. Quem entra nela muda o código e publica o que quiser. O GitHub oferece verificação em duas etapas com aplicativo autenticador, chave de segurança e passkey.
- Conta da Cloudflare e da hospedagem. Elas controlam a publicação e, com frequência, o DNS. Use senha única e verificação em duas etapas nelas também.
- Domínio e DNS. DNS (Domain Name System) é o sistema que liga o nome do site ao servidor. Quem altera o DNS desvia o tráfego para outro lugar.
- Formulários. Eles recebem dados de qualquer pessoa. O serviço que processa o envio precisa validar os dados e filtrar robôs.
- Chaves de API e dependências. Chave secreta no JavaScript do navegador vira chave pública. Biblioteca desatualizada pode trazer falha conhecida.
Para a parte de senhas, atualizações e backup, que vale para qualquer site, o guia de como proteger site de hackers já tem o passo a passo.
Cabeçalhos de segurança no Cloudflare Pages
Cabeçalhos HTTP são instruções que o servidor manda junto com a página. Alguns dizem ao navegador como se proteger. No Cloudflare Pages, você define esses cabeçalhos em um arquivo chamado _headers, sem extensão, na pasta publicada.
O exemplo abaixo segue o modelo da documentação da Cloudflare e as orientações do MDN:
/*
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; frame-ancestors 'none'
X-Content-Type-Options: nosniff
| Cabeçalho | O que faz | Cuidado antes de ativar |
|---|---|---|
| Strict-Transport-Security (HSTS) | Manda o navegador usar só HTTPS no domínio | Com includeSubDomains, todo subdomínio precisa de HTTPS |
| Content-Security-Policy (CSP) | Limita de onde a página carrega scripts e outros recursos | Libere os domínios de mapa, vídeo ou chat que você usa |
| frame-ancestors 'none' (dentro da CSP) | Impede que outro site coloque o seu dentro de um iframe | Só deixe liberado se o site precisa ser incorporado |
| X-Content-Type-Options | Evita que o navegador adivinhe o tipo do arquivo | Costuma não quebrar nada |
Sobre o HSTS, o MDN faz um alerta: o navegador ignora o cabeçalho quando ele chega por HTTP, e a opção preload é difícil de desfazer. Comece com o HTTPS funcionando em tudo. Se tem dúvida sobre certificado, a página sobre certificado SSL explica o básico.
Sobre a CSP, o MDN lembra que ela não substitui o tratamento das entradas. Ela é uma camada extra. Para testar sem bloquear nada, use primeiro Content-Security-Policy-Report-Only, que só registra o que seria barrado.
A Cloudflare limita o _headers a 100 regras e 2.000 caracteres por linha. E avisa: esses cabeçalhos não valem para respostas geradas por Pages Functions.
A criação é grátis quando você contrata uma hospedagem da HostGator em ciclo anual pelo link do MundoBlá. A gente ganha uma comissão da HostGator quando você contrata pelo link, sem custo extra para você. O escopo é combinado no WhatsApp antes de começar.
Formulários e chaves de API sem vazamento
Um site sem banco de dados ainda pode receber contato, pedido de orçamento ou cadastro. O formulário em si é HTML. O envio precisa de alguém do outro lado: um serviço externo ou uma função sua. Veja as opções em sites sem banco de dados.
O erro mais comum é colocar a chave do serviço de e-mail direto no JavaScript da página. Qualquer visitante abre o código-fonte e copia. A saída é mover essa parte para uma função no servidor, como um Cloudflare Worker, que você vê em funções dinâmicas com Cloudflare Workers.
A documentação da Cloudflare orienta guardar a chave como secret do Worker. O valor fica criptografado e não aparece depois de salvo. Para criar pelo terminal:
npx wrangler secret put CHAVE_EMAIL
No código do Worker, a chave é lida como env.CHAVE_EMAIL. Para testar no seu computador, a Cloudflare indica os arquivos .dev.vars ou .env, que precisam estar no .gitignore.
Contra robôs, a Cloudflare tem o Turnstile, apresentado na documentação como alternativa ao CAPTCHA que pode funcionar sem mostrar desafio ao visitante. Confira na documentação os planos e a validação do lado do servidor antes de usar.
E se uma chave escapou para o GitHub? Em repositório público, o secret scanning do GitHub roda de forma automática e sem custo, segundo a documentação. Mesmo assim, troque a chave na hora. Apagar o arquivo não tira a chave do histórico.
Checklist de segurança do site estático
Use esta lista antes de publicar e repita a cada 6 meses.
- Verificação em duas etapas ativa no GitHub, na Cloudflare, na hospedagem e no registro do domínio.
- HTTPS funcionando em todas as páginas e subdomínios.
- Arquivo
_headerscom HSTS, CSP testada e X-Content-Type-Options. - Nenhuma chave secreta em arquivo HTML, CSS ou JavaScript publicado.
.enve.dev.varslistados no.gitignore.- Formulário com validação no servidor e filtro contra robôs.
- Bibliotecas de JavaScript revisadas e atualizadas, ou removidas se não fazem falta.
- Scripts de terceiros só de fontes conhecidas e só onde precisam.
- Cópia local do repositório e dos dados recebidos por formulário.
Quando o estático não é a resposta
O HTML puro reduz o risco em site institucional, landing page, portfólio e catálogo. Se o projeto precisa de área de cliente com login, loja com estoque e pagamento ou equipe publicando todo dia, um sistema bem mantido pode fazer mais sentido. Um WordPress atualizado, com poucos plugins e senhas fortes, também pode ser seguro.
A comparação completa entre os dois caminhos está em WordPress ou HTML puro. E se você quer ver como código, GitHub e Cloudflare se encaixam do começo ao fim, volte ao guia de como criar sites sem WordPress. Dúvidas de outros temas têm resposta no Mundo Criação de Sites, a resposta sobre velocidade está na página de sites rápidos e a resposta para o resto começa na página inicial.
Transparência: a HostGator paga uma comissão ao MundoBlá quando você contrata a hospedagem anual pelo nosso link. Hospedagem e domínio você paga direto à HostGator, e a criação do site sai sem custo.
Em outros Mundos
Segurança também é cuidar das suas contas pessoais. No Mundo Tecnologia você encontra dicas de senha, golpe e privacidade no dia a dia.
Perguntas frequentes
Site em HTML puro pode ser invadido?
Pode, só que por menos caminhos. Sem painel de login público, sem plugin e sem banco de dados, sobram poucas portas para o invasor tentar. Os riscos que ficam estão na conta do GitHub, na conta da Cloudflare, no DNS do domínio e em qualquer formulário ou integração que você adicionar.
O que é superfície de ataque?
Superfície de ataque é o conjunto de pontos por onde alguém pode tentar entrar ou abusar de um sistema. Cada login, plugin, formulário e serviço conectado soma um ponto. Reduzir a superfície não deixa o site imune, mas diminui o número de coisas que você precisa vigiar e atualizar.
Por que o WordPress é alvo mais comum de ataque?
Porque ele roda código no servidor, tem painel de login conhecido e aceita plugins de terceiros, e cada parte pode ter falha. Ataques automáticos varrem a internet atrás dessas falhas. Um WordPress atualizado, com poucos plugins e senha forte, reduz o risco, então o problema costuma ser o descuido, não a ferramenta.
O que é a OWASP?
OWASP é a Open Web Application Security Project, uma comunidade sem fins lucrativos que publica de graça materiais sobre segurança de aplicações web, segundo a Wikipédia. Ela começou em 2001. O documento mais conhecido é o OWASP Top 10, uma lista de conscientização sobre as falhas mais importantes em aplicações web.
Site estático pode sofrer ataque de XSS?
Pode, se ele exibir conteúdo vindo de fora sem tratar, como comentários, parâmetros da URL ou dados de uma API. XSS é quando alguém consegue injetar script na página de outra pessoa. O MDN recomenda tratar as entradas e também usar Content Security Policy como camada extra de defesa.
O que é Content Security Policy?
Content Security Policy, ou CSP, é um cabeçalho que diz ao navegador de onde a página pode carregar scripts, imagens e outros recursos. O MDN explica que o uso principal é reduzir o risco de XSS. A política precisa ser testada, porque uma regra rígida demais pode quebrar mapa, chat ou vídeo.
O que é HSTS e quando ativar?
HSTS é o cabeçalho Strict-Transport-Security, que manda o navegador acessar o domínio só por HTTPS dali em diante. O MDN avisa que, com includeSubDomains, todo subdomínio precisa ter HTTPS. Ative quando todo o domínio já funcionar com certificado, e comece com um max-age menor antes de aumentar.
Preciso de certificado SSL em site estático?
Precisa. O HTTPS protege a conexão entre o visitante e o site, mesmo que a página não tenha login nem formulário. Ele também é base para o HSTS funcionar, já que o navegador ignora esse cabeçalho quando chega por HTTP, segundo o MDN. Confira com a sua hospedagem ou com a Cloudflare como o certificado é emitido e renovado.
Formulário de contato deixa o site estático vulnerável?
O formulário abre um ponto de entrada, porque recebe dados de qualquer pessoa. O risco está no serviço que processa o envio: spam, injeção de conteúdo e vazamento da chave de envio de e-mail. Valide os dados no servidor, use um desafio contra robôs e guarde as chaves fora do código.
O que é Cloudflare Turnstile?
Turnstile é a alternativa da Cloudflare ao CAPTCHA tradicional, segundo a documentação oficial. Ele roda verificações em JavaScript e pode funcionar sem mostrar desafio ao visitante. Serve para filtrar robôs em formulários, mas confira na documentação os planos e como validar o resultado no servidor antes de colocar no ar.
Posso colocar chave de API no JavaScript do site?
Não coloque chave secreta em arquivo que vai para o navegador, porque qualquer visitante pode abrir o código e copiar. Chaves públicas feitas para o navegador, como a de alguns mapas, são exceção e costumam ter restrição por domínio. A chave secreta fica em uma função no servidor, como um Cloudflare Worker.
Como guardar uma chave secreta em um Cloudflare Worker?
Use os secrets do Worker, criados com o comando wrangler secret put ou pelo painel em Variables and Secrets. A documentação da Cloudflare diz que o valor fica criptografado e não aparece depois de salvo. Não use variável de texto comum para dado sensível, e deixe os arquivos .dev.vars e .env no .gitignore.
O GitHub avisa se eu subir uma senha no repositório?
Em repositório público, o secret scanning do GitHub roda de forma automática e sem custo, segundo a documentação. Ele detecta credenciais vazadas para você trocá-las antes de alguém usar. Isso não substitui o cuidado: se uma chave foi para o histórico, troque a chave, porque apagar o arquivo depois não basta.
Por que ativar a verificação em duas etapas no GitHub?
Porque quem entra na sua conta do GitHub pode alterar o código do site e publicar o que quiser. A verificação em duas etapas pede senha e um segundo fator, como aplicativo autenticador, chave de segurança ou passkey. A mesma regra vale para a conta da Cloudflare e para o registro do domínio.
Site estático precisa de backup?
Precisa, mas fica mais simples. O código no GitHub já guarda todo o histórico de alterações, e cada commit funciona como um ponto de volta. Ainda vale ter uma cópia local do repositório e guardar fora dele os dados que chegam por formulário, porque esses não ficam no código.
Site estático pode sofrer ataque de negação de serviço?
Pode ser alvo, como qualquer endereço na internet. A diferença é que arquivos prontos e servidos por uma CDN aguentam picos de acesso com mais facilidade do que um servidor que monta cada página. A proteção depende do serviço que está na frente do site e do plano contratado.
Site em HTML é sempre a escolha mais segura?
Não sempre. Para site institucional, landing page e catálogo, o HTML puro costuma reduzir o risco porque tira painel, plugin e banco de dados do caminho. Se o projeto precisa de área de login, loja com estoque ou equipe editando diariamente, um sistema bem mantido pode fazer mais sentido.
Fontes e data de verificação
Wikipédia: OWASP, MDN: Content Security Policy, MDN: Strict-Transport-Security, Cloudflare Docs: Pages headers, Cloudflare Docs: Workers secrets, Cloudflare Docs: Turnstile, GitHub Docs: autenticação de dois fatores, GitHub Docs: secret scanning. Conferido em 5 de novembro de 2026.Referências
- Wikipédia: OWASP. Disponível em: https://pt.wikipedia.org/wiki/OWASP.
- MDN: Content Security Policy. Disponível em: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP.
- MDN: Strict-Transport-Security. Disponível em: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security.
- Cloudflare Docs: Pages headers. Disponível em: https://developers.cloudflare.com/pages/configuration/headers/.
- Cloudflare Docs: Workers secrets. Disponível em: https://developers.cloudflare.com/workers/configuration/secrets/.
- Cloudflare Docs: Turnstile. Disponível em: https://developers.cloudflare.com/turnstile/.
- GitHub Docs: autenticação de dois fatores. Disponível em: https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/about-two-factor-authentication.
- GitHub Docs: secret scanning. Disponível em: https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning.
Fontes conferidas em 05 de novembro de 2026.