Como configurar security headers completos no seu site
Os security headers são instruções enviadas pelo servidor ao navegador que definem políticas de segurança: que scripts podem executar, de onde podem vir recursos, se o site pode ser incorporado em iframes e como o navegador deve tratar a ligação HTTPS. São uma camada de proteção essencial e gratuita contra ataques como XSS, clickjacking e data injection.
Headers essenciais
Strict-Transport-Security (HSTS): força o navegador a usar sempre HTTPS, mesmo que o utilizador escreva http://. Previne ataques SSL stripping.
Este exemplo é ilustrativo. Adapte domínio, caminhos e valores ao ambiente e teste numa cópia antes de aplicar. Não repita constantes já definidas nem regras geridas por outra ferramenta.
Header always set Strict-Transport-Security "max-age=300"X-Content-Type-Options: previne MIME type sniffing: o navegador respeita o Content-Type declarado e não tenta adivinhar.
Header always set X-Content-Type-Options "nosniff"X-Frame-Options: controla se o site pode ser incorporado em iframes de outros sites. Previne clickjacking.
Header always set X-Frame-Options "SAMEORIGIN"Referrer-Policy: controla quanta informação de referrer é enviada quando o utilizador clica num link para outro site.
Header always set Referrer-Policy "strict-origin-when-cross-origin"Permissions-Policy: controla que funcionalidades do navegador o site pode usar (câmara, microfone, geolocalização).
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"Content-Security-Policy (CSP): o header mais poderoso e mais complexo. Define de onde podem vir scripts, estilos, imagens e outros recursos. Uma CSP restritiva bloqueia a maioria dos ataques XSS. A configuração depende dos recursos externos que o site usa (Google Analytics, fontes, CDNs).
Como implementar
Adicione os headers ao .htaccess na raiz do site. Para WordPress com Apache, é o método mais direto. Teste com securityheaders.com: mostra uma nota de A+ a F.
Cuidado com CSP
Uma CSP demasiado restritiva pode quebrar funcionalidades do site (scripts de terceiros bloqueados, estilos inline bloqueados). Comece com Content-Security-Policy-Report-Only para monitorizar sem bloquear, e ajuste antes de ativar em modo de bloqueio.
Aplicar políticas sem quebrar integrações
Comece por inventariar scripts, fontes, mapas e frames usados pelo site. Uma Content Security Policy demasiado restritiva pode impedir formulários e pagamentos. Teste e observe relatórios antes de impor uma política ampla.
HSTS, proteção contra framing e outras políticas têm âmbitos diferentes. Não copie uma lista e assuma que o site está protegido contra todos os ataques. Confirme cabeçalhos efetivos em páginas públicas e erros, e documente exceções. Segurança da aplicação, autenticação e atualizações continuam necessárias.
Como verificar a proteção sem criar uma falsa sensação de segurança
Uma instalação protegida combina medidas no servidor com medidas na aplicação. Atualize os componentes mantidos pelos respetivos fabricantes, elimine extensões que já não utiliza, aplique permissões adequadas e proteja as contas de administração. Uma firewall pode bloquear determinadas tentativas, mas não corrige vulnerabilidades de um plugin desatualizado.
Registe os eventos relevantes e confirme a existência de backups recuperáveis antes de intervenções de maior risco. Se houver suspeita de comprometimento, preservar registos e identificar o ponto de entrada é tão importante como repor os ficheiros. Limpar apenas a página afetada pode deixar contas fraudulentas ou tarefas maliciosas ativas. A resposta deve distinguir contenção, análise, recuperação e prevenção de reincidência.
Como agir nas primeiras horas depois de um alerta
Identifique o sistema afetado, limite acessos desnecessários e preserve registos. Não elimine ficheiros ou reinstale tudo sem compreender o alcance do incidente. Se suspeita que houve exposição de passwords, substitua-as a partir de um dispositivo de confiança e reveja os administradores existentes.
Depois da contenção, analise a origem e teste a recuperação. Restaurar um backup contaminado pode reproduzir a falha. Distinga factos confirmados de hipóteses para que a resposta não seja orientada por suposições.
Camadas de proteção com funções diferentes
SSL, firewall, proteção contra malware e backups têm objetivos distintos. O HTTPS cifra a comunicação, mas não elimina vulnerabilidades de plugins. Uma cópia de segurança apoia a recuperação, mas não substitui prevenção. A firewall pode bloquear padrões de ataque sem impedir que uma password roubada seja utilizada.
Reveja periodicamente versões, utilizadores e permissões. A empresa deve saber o que é responsabilidade do alojamento e o que pertence à manutenção da aplicação. Esta distinção facilita a resposta quando surge um incidente.
Aplicar políticas sem quebrar funções
Teste formulários, recursos externos e integrações depois de alterar cabeçalhos.
Podemos avaliar a adequação dos nossos planos de alojamento web ao site que pretende alojar. Fale connosco se precisa de ajuda a escolher.
Se já é nosso cliente, envie o contexto através de um pedido de suporte na nossa área de cliente.