Checklist de segurança para um site corporativo: o mínimo que ele deve cumprir

Um site corporativo seguro cumpre, no mínimo, sete condições: serve tudo por HTTPS com certificado válido e redirecionamento forçado; envia cabeçalhos HTTP que limitam o que o navegador pode carregar e fazer (CSP, HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy); valida os formulários no servidor e os protege contra spam; tem cópias de segurança testadas; mantém todo o software atualizado; coleta só os dados pessoais imprescindíveis; e publica um arquivo security.txt para que quem detectar uma falha saiba a quem avisar. Tudo pode ser verificado pelo navegador e pelo terminal em menos de uma hora.

A maioria dos ataques a sites de empresa não é dirigida. São programas que percorrem a internet procurando um plugin desatualizado, um formulário sem proteção ou um painel com senha fraca. Esta lista é a que reviso em cada site que entrego ou audito, seja WordPress ou sob medida.

1. HTTPS em todo o site

HTTPS criptografa a conexão entre o visitante e o servidor. Sem ele, qualquer pessoa na mesma rede pode ler o que é enviado em um formulário e modificar o que é exibido. Os navegadores marcam como «não seguro» qualquer site HTTP.

O mínimo:

• Certificado válido e renovado automaticamente. O Let's Encrypt oferece de graça e a maioria das hospedagens o integra.
• Redirecionamento 301 de todas as URLs HTTP para HTTPS, também a versão com e sem www.
• Nenhum recurso carregado por HTTP dentro de uma página HTTPS (conteúdo misto). Uma imagem ou um script em HTTP quebra o cadeado e o navegador pode bloqueá-lo.

2. Cabeçalhos HTTP de segurança

São instruções que o servidor envia ao navegador com cada resposta e que limitam o que a página pode fazer. Custam algumas linhas de configuração e fecham famílias inteiras de ataques. Os cinco que importam:

Sobre a CSP, dois avisos. Primeiro: uma política estrita pode quebrar coisas (o chat de terceiros, o analytics, as fontes externas). Comece no modo relatório com Content-Security-Policy-Report-Only, veja o que seria bloqueado e ajuste antes de ativá-la. Segundo: evite 'unsafe-inline' em script-src se puder; com isso a política perde quase todo o valor contra XSS. Se o seu site usa um gerenciador de conteúdo com scripts inline, um nonce ou um hash por script é a alternativa.

Sobre HSTS: uma vez recebido, o navegador não voltará a carregar o site por HTTP durante o tempo indicado. Se o certificado falhar, o site fica inacessível até o conserto.

3. Formulários: validar no servidor, frear o spam

O formulário de contato é a parte do site que aceita dados de desconhecidos. Duas regras:

• Validar sempre no servidor. A validação no navegador é comodidade para o usuário, não segurança: qualquer um a pula enviando a requisição diretamente. O servidor deve verificar tipo, tamanho e formato de cada campo, rejeitar o que não espera e escapar tudo o que for exibido ou guardado. Os guias da OWASP sobre validação de entrada são a referência.
• Proteger contra o envio automatizado. Três camadas que se combinam: um campo oculto (honeypot) que humanos não veem e robôs preenchem; um limite de envios por endereço IP e por minuto; e, se o spam continuar, um desafio leve (Turnstile, reCAPTCHA) como último recurso, porque adiciona atrito e, no caso de serviços externos, envia dados do visitante a um terceiro que precisa constar na política de privacidade.

Se o formulário anexa arquivos, limite tipos e tamanho e nunca os sirva a partir da mesma rota onde são enviados.

4. Cópias de segurança que já foram testadas

Uma cópia de segurança que nunca foi restaurada é uma hipótese. O mínimo:

• Cópia automática diária de arquivos e banco de dados, com retenção de pelo menos 30 dias.
• Pelo menos uma cópia fora do servidor de produção (outro provedor ou armazenamento independente). Se o servidor cair ou for criptografado, a cópia que estava nele cai junto.
• Uma restauração de teste a cada trimestre, em um ambiente separado, cronometrada. O tempo que leva é o seu tempo real de recuperação.
• Cópia manual antes de cada atualização importante.

5. Atualizações e superfície de ataque

A maioria das invasões em sites de empresa explora vulnerabilidades já conhecidas e já corrigidas em software que ninguém atualizou. No WordPress, o grosso está em plugins e temas, não no núcleo. Em um site sob medida, nas bibliotecas e no sistema do servidor.

• Atualize o núcleo, os plugins, o tema e as dependências pelo menos uma vez por mês, com cópia prévia e verificação posterior.
• Elimine o que não usa: plugins desativados, temas antigos, contas de usuários que já saíram, arquivos de instalação. O que não existe não pode ser atacado.
• Proteja o painel de administração: senhas longas e únicas, segundo fator de autenticação, limite de tentativas de acesso e, se possível, acesso restrito por IP ou por VPN.
• Revise quem tem acesso à hospedagem, ao domínio e ao painel, e com quais permissões.

6. Mínimo de dados pessoais

Segurança e proteção de dados se cruzam aqui. O RGPD exige coletar só os dados necessários para a finalidade (artigo 5) e protegê-los com medidas técnicas adequadas (artigo 32). Para um site corporativo isso se traduz em:

• Formulários que pedem o imprescindível. Se para responder a uma consulta bastam nome e e-mail, não peça telefone, empresa e cargo como obrigatórios.
• Informação clara no momento da coleta: quem trata os dados, para quê, por quanto tempo e como exercer os direitos. Vinculada a partir do próprio formulário.
• Prazos de conservação definidos e aplicados: as mensagens de contato de quatro anos atrás não deveriam continuar no banco de dados do site.
• Cookies e scripts de terceiros só com consentimento prévio quando não forem tecnicamente necessários, seguindo o guia de cookies da AEPD.
• Um procedimento para avisar a AEPD em 72 horas se houver um vazamento que afete dados pessoais (artigo 33). Saber a quem ligar antes de precisar.

7. security.txt

Se alguém descobrir uma falha de segurança no seu site, como avisa você? O padrão security.txt (RFC 9116) resolve isso com um arquivo de texto em /.well-known/security.txt que indica um contato, uma data de expiração e, opcionalmente, um idioma preferido e uma política de divulgação. Exemplo mínimo:

Contact: mailto:[email protected]
Expires: 2027-10-29T00:00:00.000Z
Preferred-Languages: pt, es, en

O campo Expires é obrigatório e convém que não ultrapasse um ano. Coloque uma data no calendário para renová-lo.

Tabela de verificação

Imprima ou copie para uma planilha compartilhada. Revise ao entregar o site e depois a cada três meses.

A segurança de um site corporativo não se compra uma vez. Revisa-se a cada trimestre.

Se você quiser que eu revise o seu com esta lista, o serviço de desenvolvimento web inclui uma auditoria técnica inicial, e a manutenção recorrente cobre as verificações mensais e trimestrais. Você também pode me escrever com o resultado da sua própria revisão.