“Tem HTTPS, então é seguro.” É o que a maioria pensa - e é exatamente onde mora o risco. Segurança de site não é o cadeado: é cada superfície onde o site toca o usuário ou os dados dele. São três, e o site vale o elo mais fraco: a conexão (HTTPS e cabeçalhos), os formulários (onde os dados entram) e os pagamentos (onde o cartão e o dinheiro passam). Este artigo cobre as três, com dados recentes e de fontes primárias.
Principais pontos
- Segurança não é só HTTPS: a maioria dos sites falha no básico invisível - cerca de 64% não têm HSTS e 78% não têm CSP (Web Almanac 2025).
- Os ataques são automatizados e rápidos: o tráfego automatizado já passa de metade da web (Imperva/Thales, 2025 - estudo de fornecedor), e uma falha divulgada é explorada em ~5 horas, em mediana (Patchstack, 2026).
- Formulários são a porta menos trancada: viram relay de spam, vetor de injeção e ponto de vazamento de dados pessoais (PII) - risco direto sob a LGPD.
- Se você aceita pagamento, a regra é não tocar no cartão: páginas de pagamento hospedadas pelo gateway tiram seu site do alvo do e-skimming, que infectou mais de 11 mil domínios em 2024.
- Custa caro: o vazamento médio no Brasil chegou a R$ 7,19 milhões em 2025 (IBM), e a LGPD exige medidas de segurança e, pela regulamentação da ANPD, comunicação de incidentes relevantes em 3 dias úteis.
A base: conexão e cabeçalhos
HTTPS é o piso, não o teto. Hoje cerca de 88% dos sites usam HTTPS, mas a camada que de fato endurece a conexão - os security headers - quase ninguém implementa. Segundo o Web Almanac 2025 (análise independente de milhões de sites), só ~36% têm HSTS e cerca de 22% têm CSP (ou seja, ~64% sem HSTS e quase 8 em cada 10 sem CSP). O que cada um faz:
- HSTS força o navegador a sempre usar HTTPS, bloqueando downgrade e interceptação.
- CSP (Content-Security-Policy) define quais scripts a página pode executar - a principal defesa contra XSS.
- X-Frame-Options impede que sua página seja embutida em iframe de outro site (clickjacking).
- X-Content-Type-Options, Referrer-Policy e Permissions-Policy fecham vetores menores, mas reais.
E o certificado precisa estar válido. Um SSL expirado faz o navegador estampar “não seguro”, afugenta o visitante e derruba ranqueamento - o Google trata HTTPS como sinal desde 2014 (Google Search Central). Pior: a validade máxima dos certificados vai cair drasticamente nos próximos anos (rumo a 47 dias até 2029, decisão do CA/Browser Forum), o que torna a gestão manual insustentável. Renovação automatizada deixou de ser luxo.
O alvo favorito: CMS e plugins desatualizados
A maioria dos sites institucionais roda WordPress, e é aí que mora o maior volume de ataque. Entre os sites que a Sucuri limpa - base majoritariamente WordPress, então leia com essa ressalva - o WordPress aparece na esmagadora maioria das infecções, e 39% estavam desatualizados no momento do ataque (Sucuri). E o problema não é o núcleo: em 2025, o Patchstack catalogou 11.334 novas vulnerabilidades no ecossistema WordPress - 91% em plugins, 9% em temas e apenas 6 no core (Patchstack, 2026).
A janela de reação é brutal: a mediana entre a divulgação de uma falha e a primeira exploração é de ~5 horas, e 45% dos ataques acontecem nas primeiras 24 horas (Patchstack, 2026). Como tudo é automatizado - só a Wordfence bloqueou mais de 54 bilhões de requisições maliciosas em 2024 (Wordfence) - atualizar “quando der” não é estratégia. O site precisa de superfície mínima (menos plugins), atualização disciplinada e monitoramento.
Formulários: a porta que quase ninguém tranca
Todo site institucional tem formulários - contato, orçamento, newsletter, currículo. E quase todos tratam isso como detalhe de front-end. É um erro, porque o formulário é onde dados não confiáveis entram no seu sistema. Os riscos, segundo a OWASP:
- Injeção (SQL Injection e XSS).Um campo “mensagem” pode receber código disfarçado de texto. Sem tratamento, um atacante lê ou apaga seu banco (SQLi), ou injeta um script que roda no navegador de outros visitantes (XSS). A defesa é validação no servidor (allowlist) e queries parametrizadas (OWASP - Input Validation).
- Email injection / relay de spam. Um formulário de contato mal feito (usando
mail()do PHP sem sanitizar) permite injetar cabeçalhos e transformar seu site numa máquina de spam. Não é teórico: a Sucuri documentou um caso em que bots geraram 149.700 e-mails a partir de formulários vulneráveis (Sucuri, 2025). - CSRF. Sem token de proteção, uma ação pode ser forjada a partir de outro site enquanto o usuário está logado (OWASP - CSRF).
- Upload malicioso. Formulário de currículo ou orçamento que aceita anexo é porta para webshell e malware. A regra da OWASP: aceitar só as extensões necessárias (
.pdf,.docx), nunca confiar no Content-Type, renomear o arquivo e guardá-lo fora do diretório público. Nunca aceitar.exe,.zip,.htmlou.svg. - Spam de bot. Segundo o relatório Imperva/Thales (2025), o tráfego automatizado chegou a 51% do tráfego web em 2024 - é estudo de fornecedor de segurança, então leia como sinal forte de direção, não censo da web inteira (Imperva, 2025). Mesmo assim, formulários sem proteção viram lixeira. A defesa eficaz é em camadas: honeypot (campo oculto), rate limiting, e um desafio anti-bot moderno (reCAPTCHA, hCaptcha ou Cloudflare Turnstile) - nenhum sozinho resolve.
E há a camada de dados pessoais. Nome, e-mail e telefone num formulário são dado pessoal sob a LGPD (Lei 13.709/2018). Um formulário que despeja tudo num e-mail em texto puro cria uma trilha de PII sem controle de acesso, retenção ou descarte - o oposto do que o Art. 46 exige. Coletar com base legal, trafegar com segurança e guardar com controle não é zelo extra: é a lei.
Pagamentos simples: onde o erro custa caro
Cada vez mais site institucional aceita algum pagamento - uma doação, um link de pagamento, um checkout simples. E aqui o princípio é um só, e libertador: não toque no cartão.
O ataque dominante hoje é o e-skimming (ou Magecart): um script malicioso injetado na página de checkout que rouba os dados do cartão enquanto o cliente digita, antes de a transação seguir - invisível no servidor (Visa - Digital Skimming). A escala explodiu: a Visa registrou +7% de sites infectados no 2º semestre de 2024 (Visa PERC, 2025), e a Sansec, referência em Magecart, segue documentando infecções em massa (Sansec).
Foi por causa do e-skimming que o PCI DSS 4.0.1 passou a exigir, desde 31 de março de 2025, controle dos scripts da página de pagamento (req. 6.4.3) e detecção de adulteração (req. 11.6.1) (PCI SSC). A boa notícia para sites pequenos: dá para sair quase inteiro do escopo. Usando uma página de pagamento hospedada pelo gateway (redirect ou iframe), os dados do cartão vão direto para os servidores do gateway, nunca passando pelo seu - é o que qualifica o comerciante ao questionário mais simples (SAQ A) (PCI SSC). Gateways como Stripe, Mercado Pago, PagBank e Pagar.me oferecem exatamente isso; a Stripe, por exemplo, documenta que seus campos são renderizados em iframes hospedados e nunca tocam seu servidor (Stripe).
Dois cuidados que muita gente erra:
- Nunca armazene dados de cartão. O PCI proíbe guardar CVV, faixa magnética e PIN - mesmo criptografados. Quem não armazena nada elimina o alvo (PCI SSC - Data Storage).
- Cuidado com scripts na página de checkout. O iframe hospedado só protege se a página de pagamento não for contaminada por scripts próprios (Google Tag Manager, pixel, analytics) - foi assim que ataques recentes contornaram a proteção. Alinhado ao PCI (req. 6.4.3 e 11.6.1), a página de pagamento é zona controlada: evite scripts próprios sempre que possível e, quando forem inevitáveis, mantenha-os inventariados, autorizados, justificados e monitorados contra alteração.
O custo e a lei
Por que isso tudo importa em reais? Porque um vazamento custa, em média, R$ 7,19 milhões no Brasil (IBM, 2025) - e o dano de reputação vem junto: cerca de 70% dos consumidoresdizem que deixariam de comprar de uma marca após um incidente. No lado legal, a LGPD obriga medidas técnicas de segurança “desde a concepção” (Art. 46) e, pela regulamentação da ANPD, comunicação - em até 3 dias úteis - dos incidentes de segurança que possam acarretar risco ou dano relevante aos titulares (ANPD - Resolução 15/2024), com multa que pode chegar a 2% do faturamento, limitada a R$ 50 milhões por infração.
A síntese
Segurança de site é a soma de três superfícies - conexão, formulários e pagamentos - e o site é tão seguro quanto a mais fraca delas. Um cadeado HTTPS por cima de um formulário vulnerável ou de um checkout exposto não é segurança: é fachada.
A boa notícia é que nada disso é mágica. É engenharia e disciplina: HTTPS com headers e certificado válido, superfície mínima e atualizada, formulários com validação no servidor e anti-bot, dados pessoais tratados conforme a lei, e pagamentos que nunca tocam o cartão. Quase ninguém faz as três - e é exatamente aí que está a diferença.
Na Inodus, Security Headers A/A+ e arquitetura segura são requisito de partida - da conexão ao checkout. Quer ver onde seu site está exposto? Faça o diagnóstico online gratuito.
Perguntas frequentes
HTTPS já não basta para um site ser seguro?+
Não. HTTPS protege a conexão, mas não os formulários, os uploads, os dados pessoais nem a página de pagamento. Segurança real cobre as três superfícies: conexão, formulários e pagamentos.
O que são security headers e por que importam?+
São instruções que o servidor envia ao navegador para bloquear ataques comuns (XSS, clickjacking, downgrade de conexão). A maioria dos sites não os tem - cerca de 64% sem HSTS e quase 8 em cada 10 sem CSP (Web Almanac 2025).
Como deixar um formulário de contato seguro?+
Validação no servidor (não só no navegador), sanitização para evitar injeção, proteção anti-bot (honeypot + rate limit + CAPTCHA/Turnstile), upload restrito a tipos seguros e tratamento dos dados pessoais conforme a LGPD (OWASP).
Meu site aceita pagamento. Preciso ser PCI DSS?+
Se você usar uma página de pagamento hospedada pelo gateway (redirect ou iframe), os dados do cartão nunca passam pelo seu servidor e você se enquadra no nível mais simples (SAQ A) (PCI SSC). A regra de ouro é não tocar no cartão.
O que é e-skimming?+
É um script malicioso injetado na página de checkout que rouba os dados do cartão enquanto o cliente digita (Visa). Usar campos de pagamento hospedados pelo gateway e manter a página de checkout livre de scripts próprios é a principal defesa.
Como interpretamos as fontes deste artigo
Este conteúdo diferencia quatro tipos de evidência: documentação oficial, estudos de caso publicados por fontes reconhecidas, estudos proprietários de mercado e pesquisas ou análises emergentes. Dados oficiais são tratados como referência normativa. Estudos proprietários e benchmarks são usados como sinal de direção, não como regra universal. Pesquisas acadêmicas e análises de logs sobre IA são apresentadas como evidência técnica em evolução, especialmente quando ainda não existem thresholds públicos definidos pelos fabricantes.
Metodologia e fontes
Padrões técnicos de fontes primárias: OWASPoficial (formulários e injeção); PCI Security Standards Counciloficial (pagamentos); HTTP Archive - Web Almanacpesquisa/análise (headers); Google e Visaoficial. Base legal: LGPD (Planalto) e ANPD (Resolução 15/2024)oficial. Dados de incidência (Sucuri, Patchstack, Wordfence, Imperva)proprietário são de fornecedores de segurança e citados como tais; o percentual de WordPress nas infecções reflete a base de clientes da Sucuri, não o universo da web. Este artigo é informativo e não constitui aconselhamento jurídico.