Diretrizes básicas de segurança para aplicações web

Hoje a maior parte das interações e transações ocorre online, as aplicações web se tornaram ferramentas indispensáveis para empresas, instituições e usuários. Contudo, essa dependência do ambiente virtual também trouxe à tona uma preocupação crescente: a segurança. Falhas em segurança podem resultar em violações de dados, perda de confiança dos usuários, prejuízos financeiros e danos irreparáveis à reputação de uma marca.

Com o aumento do número de ataques cibernéticos, desde invasões simples até ameaças mais sofisticadas, como ransomware e engenharia social, torna-se fundamental que desenvolvedores, gestores de tecnologia e equipes responsáveis por aplicações web estejam atualizados sobre as boas práticas de segurança. Essas diretrizes ajudam a mitigar riscos, proteger dados sensíveis e garantir a continuidade e integridade dos sistemas.

Investir em segurança não é apenas uma questão técnica, mas também estratégica. Demonstrar um compromisso com a proteção de dados dos usuários é um diferencial competitivo e um pilar essencial para o sucesso sustentável de qualquer aplicação web.

Este artigo foi baseado no documento Web Security da Mozilla e explora as principais diretrizes e boas práticas que devem ser conhecidas e aplicadas para reduzir vulnerabilidades e construir aplicações mais seguras, confiáveis e alinhadas às expectativas de um mundo cada vez mais conectado.

Resumo de Segurança da Web

Este resumo apresenta diretrizes essenciais para garantir a segurança de aplicações web, classificando cada prática com base em sua importância, dificuldade de implementação e ordem de prioridade. Confira abaixo as recomendações:

Diretriz	Dificuldade	Observações
HTTPS	MÉDIA	Todas as comunicações de sites devem usar HTTPS ou protocolos seguros equivalentes.
Redirecionamentos de HTTP	BAIXA	Todos os sites devem redirecionar automaticamente para HTTPS. APIs devem desativar HTTP.
Carregamento de Recursos	BAIXA	Tanto recursos passivos quanto ativos devem ser carregados exclusivamente por protocolos TLS.
Segurança Rígida de Transporte (HSTS)	BAIXA	Deve ser configurado com um período mínimo de seis meses.
Configuração TLS	MÉDIA	Utilize a configuração TLS mais segura, como a “Intermediária” recomendada pela Mozilla.
Política de Segurança de Conteúdo (CSP)	ALTA	Recomendado para sites existentes. Foque em desabilitar scripts inline para maior proteção.

---

Leia também: Como remover o meu website de uma blacklist

---

Segurança Rígida de Transporte HTTP (HTTP Strict Transport Security – HSTS)

A Segurança Rígida de Transporte HTTP (HSTS) é um cabeçalho HTTP que informa aos navegadores para se conectar a um site apenas via HTTPS, mesmo que o esquema original seja HTTP. Navegadores que recebem a configuração HSTS para um site atualizarão automaticamente todas as solicitações para HTTPS. Além disso, o HSTS instrui os navegadores a tratar erros relacionados ao TLS e aos certificados de forma mais rigorosa, desabilitando a possibilidade de os usuários ignorarem a página de erro.

O cabeçalho HSTS consiste em um parâmetro obrigatório (max-age) e dois opcionais (includeSubDomains e preload), separados por ponto e vírgula.

Diretivas

• max-age: Define por quanto tempo os navegadores devem redirecionar para HTTPS, em segundos.
• includeSubDomains: Indica se os navegadores devem atualizar solicitações de subdomínios.
• preload: Permite que o site seja incluído na lista de pré-carregamento de HSTS.

O valor de max-age deve ser configurado para um período mínimo de seis meses (15768000 segundos). Períodos mais longos, como dois anos (63072000 segundos), são recomendados. Uma vez configurado, o site deve continuar a oferecer suporte ao HTTPS até que o tempo de expiração seja atingido.

A diretiva includeSubDomains notifica o navegador que todos os subdomínios da origem atual também devem ser atualizados via HSTS. Cuidados devem ser tomados ao habilitar essa configuração, pois ela pode desativar sites em subdomínios que ainda não possuem HTTPS habilitado.

A diretiva preload permite que o site seja incluído na lista de pré-carregamento de HSTS. Navegadores farão atualizações automáticas para HTTPS sem a necessidade de receber o cabeçalho inicial. Isso é recomendado para sites de alto risco, mas exige que includeSubDomains também esteja configurado.

Exemplos

Conectar-se ao site apenas via HTTPS pelos próximos dois anos:

Strict-Transport-Security: max-age=63072000

Conectar-se ao site e subdomínios via HTTPS pelos próximos dois anos e incluir na lista de pré-carregamento:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Redirecionamentos HTTP

Os sites podem continuar ouvindo na porta 80 (HTTP) para evitar que os usuários recebam erros de conexão ao digitar um URL na barra de endereços, já que os navegadores frequentemente fazem a primeira solicitação via HTTP. No entanto, os sites que ouvem na porta 80 devem redirecionar para o mesmo recurso em HTTPS. Após o redirecionamento, o HSTS deve garantir que todas as futuras tentativas de acesso ao site via HTTP sejam diretamente enviadas ao site seguro.

Pontos de extremidade de APIs ou sites que não são destinados ao público geral devem desativar completamente o uso de HTTP.

Evite redirecionamentos de HTTP para HTTPS em um host diferente, pois isso impede a configuração do HSTS. Por exemplo, ao redirecionar, use o seguinte fluxo:

1. Certo: Primeiro redirecione de http://exemplo.com/ para https://exemplo.com/ e, depois, de https://exemplo.com/ para https://outroexemplo.com/.
2. Errado: Redirecionar diretamente de http://exemplo.com/ para https://outroexemplo.com/.

Exemplos de Implementação

Redirecionar todas as solicitações HTTP para o mesmo recurso em HTTPS utilizando nginx:

server { 
listen 80; 
return 301 https://$host$request_uri; 
}

Redirecionar solicitações de http://site.exemplo.org/ para https://site.exemplo.org/ utilizando Apache:

<VirtualHost *:80> 

ServerName site.exemplo.org 

Redirect permanent / https://site.exemplo.org/ 

</VirtualHost>

Política de Segurança de Conteúdo (Content Security Policy – CSP)

A Política de Segurança de Conteúdo (CSP) é um cabeçalho HTTP que permite aos operadores de sites controlar detalhadamente de onde os recursos de seu site podem ser carregados. O uso desse cabeçalho é o melhor método para prevenir vulnerabilidades de cross-site scripting (XSS). Devido à dificuldade em implementar CSP em sites já existentes, ele é obrigatório para todos os novos sites e fortemente recomendado para sites de alto risco já existentes.

Benefícios Primários

O principal benefício do CSP vem da desativação do uso de JavaScript inline inseguro. JavaScript inline — seja refletido ou armazenado — permite que entradas de usuários mal escapadas gerem código que o navegador interpreta como JavaScript. Ao usar CSP para desabilitar JavaScript inline, é possível eliminar quase todos os ataques XSS contra o site.

Note que desabilitar JavaScript inline significa que todo o JavaScript deve ser carregado a partir de tags <script> com atributo src. Manipuladores de eventos como onclick utilizados diretamente em tags falharão, assim como JavaScript dentro de tags <script> sem src. Além disso, estilos inline em tags <style> ou no atributo style também falharão ao carregar. Portanto, é necessário cuidado no design dos sites para facilitar a implementação do CSP.

Notas de Implementação

• Configurar o CSP para default-src https: é um ótimo primeiro objetivo, pois desativa códigos inline e exige HTTPS.
• Para sites existentes com grandes bases de código que tornariam inviável desativar scripts inline, default-src https: 'unsafe-inline' ainda é útil, pois impede o carregamento de recursos via HTTP, mas não oferece proteção contra XSS.
• Recomenda-se começar com uma política restritiva, como default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; e adicionar fontes conforme necessário durante os testes.
• Em vez de usar o cabeçalho HTTP preferido, as páginas podem incluir uma tag <meta http-equiv="Content-Security-Policy" content="...">. Se o fizerem, ela deve ser a primeira <meta> dentro da tag <head>.
• Tenha cuidado com URIs no formato data:, pois são inseguros dentro de script-src e object-src (ou herdados de default-src).
• Evite o uso de script-src 'self' para sites com endpoints JSONP. Eles devem especificar caminhos seguros para os diretórios que contenham os scripts.
• Caso o site não exija a execução de plugins como Flash ou Silverlight, desabilite-os com object-src 'none'.
• Utilize a diretiva report-uri para receber relatórios em formato JSON sobre violações de CSP, permitindo correções rápidas.

Antes da implementação, recomenda-se o uso do cabeçalho Content-Security-Policy-Report-Only para monitorar possíveis violações.

Exemplos

Desabilitar código inline/eval e permitir recursos somente via HTTPS:

Content-Security-Policy: default-src https:

Política semelhante usando uma tag :

<meta http-equiv="Content-Security-Policy" content="default-src https:">

Desabilitar plugins e permitir recursos da mesma origem e imagens de uma origem específica:

Content-Security-Policy: default-src 'self'; img-src 'self' https://i.imgur.com; object-src 'none'

Relatar violações sem implementar a política ainda:

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/

Compartilhamento de Recursos Entre Origens (Cross-Origin Resource Sharing – CORS)

O cabeçalho HTTP Access-Control-Allow-Origin define quais origens externas têm permissão para acessar o conteúdo das páginas em seu domínio por meio de métodos como XMLHttpRequest. Arquivos como crossdomain.xml e clientaccesspolicy.xml fornecem funcionalidades semelhantes para aplicações baseadas em Flash e Silverlight, respectivamente.

Esses arquivos ou cabeçalhos não devem estar presentes, a menos que sejam especificamente necessários. Casos de uso válidos incluem redes de entrega de conteúdo (CDNs) que hospedam bibliotecas de JavaScript/CSS e endpoints de APIs públicas. Se presentes, eles devem ser limitados ao mínimo de origens e recursos necessários para o funcionamento correto.

Por exemplo, se o servidor fornece um site e uma API destinada ao acesso por meio de XMLHttpRequest em sites remotos, apenas os recursos da API devem retornar o cabeçalho Access-Control-Allow-Origin. O não cumprimento desta prática permite que origens externas leiam o conteúdo de qualquer página do seu domínio.

Exemplos

Permitir que qualquer site leia o conteúdo desta biblioteca JavaScript, para que a integridade de subrecursos funcione:

Access-Control-Allow-Origin: *

Permitir que apenas https://dashboard.exemplo.org leia os resultados retornados por esta API:

Access-Control-Allow-Origin: https://dashboard.exemplo.org

Permitir que o Flash de https://dashboard.exemplo.org leia conteúdos da página:

<cross-domain-policy xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
  <allow-access-from domain="dashboard.exemplo.org"/>
  <site-control permitted-cross-domain-policies="master-only"/>
  <allow-http-request-headers-from domain="dashboard.exemplo.org" headers="*" secure="true"/>
</cross-domain-policy>

Permitir o mesmo para Silverlight:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="https://dashboard.exemplo.org"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Prevenção de CSRF (Cross-Site Request Forgery)

Ataques de falsificação de solicitações entre sites (CSRF) são uma classe de ataques em que comandos não autorizados são transmitidos a um site a partir de um usuário confiável. Como esses ataques herdam os cookies do usuário (e, portanto, informações de sessão), eles parecem comandos válidos. Um ataque CSRF pode se parecer com isto:

<!-- Tentativa de excluir a conta de um usuário -->
<img src="https://contas.exemplo.org/gerenciamento/excluir?confirmar=true">

Quando um usuário visita uma página com esse fragmento de HTML, o navegador tentará fazer uma solicitação GET para aquele URL. Se o usuário estiver autenticado, o navegador enviará seus cookies de sessão, e a tentativa de exclusão da conta será bem-sucedida.

Embora existam várias estratégias de mitigação, como verificações de Origem/Referer e sistemas de desafio-resposta (como CAPTCHA), o método mais comum e transparente de mitigar CSRF é por meio do uso de tokens anti-CSRF. Esses tokens evitam ataques CSRF exigindo a existência de um token secreto, único e imprevisível em todas as alterações destrutivas. Esses tokens podem ser configurados para toda a sessão do usuário, rotacionados regularmente ou criados de forma única para cada solicitação.

Embora os cookies SameSite sejam a melhor defesa contra ataques CSRF, eles ainda não são totalmente suportados em todos os navegadores. Portanto, devem ser usados em conjunto com outras medidas anti-CSRF.

Exemplos

Um token anti-CSRF secreto incluído em um formulário para excluir uma conta:

<input type="hidden" name="csrftoken" value="1df93e1eafa42012f9a8aff062eeb1db0380b">

Servidor define um cookie anti-CSRF que o JavaScript deve enviar como um cabeçalho X:

Set-Cookie: CSRFTOKEN=1df93e1eafa42012f9a8aff062eeb1db0380b; Path=/; Secure; SameSite=Strict

No cliente, o JavaScript adiciona o token como um cabeçalho X-CSRF-Token na solicitação XMLHttpRequest:

var token = readCookie('CSRFTOKEN'); // lê o cookie
httpRequest.setRequestHeader('X-CSRF-Token', token); // adiciona como cabeçalho X-CSRF-Token

Política de Referência (Referrer Policy)

Quando um usuário navega para um site por meio de um hiperlink ou quando um site carrega um recurso externo, os navegadores informam ao site de destino a origem da solicitação usando o cabeçalho HTTP Referer (sic). Embora isso possa ser útil para diversos fins, também pode colocar em risco a privacidade dos usuários. A Política de Referência permite que os sites tenham controle detalhado sobre como e quando os navegadores transmitem o cabeçalho Referer.

Em navegadores legados, se uma página em https://exemplo.com/pagina.html contiver <img src="https://nao.exemplo.com/imagem.jpg">, o navegador enviará uma solicitação assim:

GET /imagem.jpg HTTP/1.1
Host: nao.exemplo.com
Referer: https://exemplo.com/pagina.html

Além dos riscos à privacidade, o navegador pode também transmitir URLs de uso interno que não eram destinados a serem revelados. Se você, como operador do site, quiser limitar a exposição dessa informação, pode usar a Política de Referência para eliminar o cabeçalho Referer ou reduzir a quantidade de informações que ele contém.

Diretivas

• no-referrer: Nunca enviar o cabeçalho Referer.
• same-origin: Enviar o cabeçalho Referer, mas apenas em solicitações para a mesma origem.
• strict-origin: Enviar o referenciador para todas as origens, mas apenas com o URL sem o caminho (por exemplo, https://exemplo.com/).
• strict-origin-when-cross-origin: Enviar o referenciador completo na mesma origem e apenas o URL sem o caminho para origens externas.

Observações

• Embora existam outras opções para políticas de referência, elas não protegem a privacidade do usuário nem limitam a exposição da mesma maneira que as opções listadas acima.
• A diretiva strict-origin-when-cross-origin é o comportamento padrão em todos os navegadores modernos.
• A Política de Referência é bem suportada por navegadores modernos. Em versões recentes do Firefox e Safari, diretivas “não seguras” (como no-referrer-when-downgrade, origin-when-cross-origin e unsafe-url) comportam-se como o padrão strict-origin-when-cross-origin.

Exemplos

Em exemplo.com, enviar o cabeçalho Referer apenas ao carregar ou vincular a outros recursos de exemplo.com:

Referrer-Policy: same-origin

Enviar o referenciador encurtado para uma origem externa e o referenciador completo para o host local:

Referrer-Policy: strict-origin-when-cross-origin

Desabilitar referenciadores para navegadores que não suportam strict-origin-when-cross-origin:

Referrer-Policy: no-referrer, strict-origin-when-cross-origin

Configurar a política com uma tag :

<meta http-equiv="Referrer-Policy" content="no-referrer, strict-origin-when-cross-origin">

Configuração direta no elemento HTML:

<a href="https://exemplo.org/" referrerpolicy="no-referrer">

robots.txt

O arquivo robots.txt é um arquivo de texto colocado no diretório raiz de um site para informar aos robôs (como indexadores usados por motores de busca) como se comportar, instruindo-os a não rastrear determinados caminhos no site. Isso é particularmente útil para reduzir a carga no site ao desabilitar o rastreamento de conteúdo gerado automaticamente. Também pode ser útil para evitar a poluição de resultados de busca, especialmente para recursos que não beneficiam a indexação.

Os sites podem usar o robots.txt opcionalmente, mas ele deve ser usado apenas para esses propósitos. Ele não deve ser utilizado para prevenir a divulgação de informações privadas ou para ocultar partes do site. Embora isso impeça que esses conteúdos apareçam em motores de busca, não previne a descoberta por atacantes, já que o arquivo robots.txt frequentemente é usado como fonte de reconhecimento.

Exemplos

Bloquear todos os motores de busca de rastrear este site:

User-agent: *
Disallow: /

Tentar ocultar certos diretórios usando robots.txt (método não recomendado):

User-agent: *
Disallow: /secret/admin-interface

Integridade de Subrecursos (Subresource Integrity – SRI)

A Integridade de Subrecursos (SRI) é um padrão recente do W3C que protege contra ataques que modificam o conteúdo de bibliotecas JavaScript hospedadas em redes de entrega de conteúdo (CDNs) para criar vulnerabilidades em todos os sites que utilizam essas bibliotecas.

Por exemplo, o código JavaScript em jquery.org carregado a partir de example.org tem acesso total ao conteúdo do site example.org. Se esse recurso for comprometido, ele pode modificar links de download, desfigurar o site, roubar credenciais, causar ataques de negação de serviço (DoS) e mais.

O SRI bloqueia um recurso externo de JavaScript a um conteúdo conhecido em um ponto específico no tempo. Caso o arquivo seja modificado posteriormente, navegadores compatíveis se recusarão a carregá-lo. Assim, o uso do SRI é obrigatório para todos os recursos JavaScript externos carregados de fontes não controladas pela Mozilla.

Observações

Os CDNs devem oferecer suporte ao padrão Cross-Origin Resource Sharing (CORS) configurando o cabeçalho Access-Control-Allow-Origin. A maioria dos CDNs já suporta isso, mas, caso o CDN utilizado não suporte o CORS, entre em contato com a equipe de Garantia de Segurança para suporte.

Diretivas

• integrity: Um hash criptográfico do arquivo, precedido pela função hash usada para gerá-lo.
• crossorigin: Deve ser configurado como anonymous para informar aos navegadores que enviem solicitações anônimas sem cookies.

Exemplos

Carregar o jQuery 2.1.4 de um CDN com SRI habilitado:

<script src="https://code.jquery.com/jquery-2.1.4.min.js"
        integrity="sha384-R4/ztc4ZlRqWjqIuvf6RX5yb/v90qNGx6fS48N0tRxiGkqveZETq72KgDVJCp2TC"
        crossorigin="anonymous"></script>

Opções de Tipo de Conteúdo (X-Content-Type-Options)

O cabeçalho HTTP X-Content-Type-Options é suportado pelos navegadores Internet Explorer, Chrome e Firefox (a partir da versão 50) e instrui-os a não carregar scripts e folhas de estilo, a menos que o servidor indique o tipo MIME correto. Sem esse cabeçalho, esses navegadores podem detectar incorretamente arquivos como scripts e folhas de estilo, o que pode levar a ataques de cross-site scripting (XSS).

Portanto, todos os sites devem configurar o cabeçalho X-Content-Type-Options e os tipos MIME apropriados para os arquivos que servem.

Exemplos

Prevenir que navegadores detectem incorretamente arquivos que não sejam scripts como sendo scripts:

X-Content-Type-Options: nosniff

Opções de Quadro (X-Frame-Options)

O cabeçalho HTTP X-Frame-Options permite que os sites controlem como podem ser incorporados em um iframe. O clickjacking é um ataque prático que permite que sites maliciosos enganem os usuários para clicarem em links em seu site, mesmo que pareça que eles não estão em seu site. Portanto, o uso do cabeçalho X-Frame-Options é obrigatório para todos os novos sites, e os sites existentes devem adicioná-lo o mais rápido possível.

O X-Frame-Options foi substituído pela diretiva frame-ancestors da Política de Segurança de Conteúdo (CSP), que oferece controle muito mais granular sobre as origens autorizadas a incorporar o site. Como frame-ancestors ainda não é suportado no IE11 e versões anteriores, Edge, Safari 9.1 (desktop) e Safari 9.2 (iOS), recomenda-se que os sites usem o X-Frame-Options além da CSP.

Sites que exigem a capacidade de serem incorporados em iframes devem usar a Política de Segurança de Conteúdo (CSP) e/ou empregar defesas em JavaScript para prevenir ataques de clickjacking de origens maliciosas.

Diretivas

• DENY: Bloqueia qualquer tentativa de incorporar o site em iframes (recomendado).
• SAMEORIGIN: Permite que o site se incorpore em iframes em sua própria origem.
• ALLOW-FROM uri: Diretiva descontinuada; utilize a diretiva frame-ancestors da CSP no lugar.

Exemplos

Bloquear o site de ser incorporado usando X-Frame-Options e CSP:

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY

Permitir que apenas o próprio site se incorpore:

Content-Security-Policy: frame-ancestors 'self'
X-Frame-Options: SAMEORIGIN

Permitir que apenas framer.exemplo.org incorpore o site:

Content-Security-Policy: frame-ancestors https://framer.exemplo.org
X-Frame-Options: DENY

Implementando e Verificando a Segurança de Aplicações Web

A segurança de aplicações web é um componente essencial para proteger os dados e a privacidade dos usuários. Este documento apresentou um conjunto abrangente de diretrizes que, se implementadas corretamente, ajudam a mitigar riscos e vulnerabilidades comuns. No entanto, a implementação dessas diretrizes é apenas o primeiro passo. Testar e validar regularmente essas configurações é igualmente crucial para garantir que estejam funcionando conforme o esperado.

Para auxiliar no processo de verificação, existem ferramentas online que podem analisar seu site e fornecer relatórios detalhados sobre a implementação das melhores práticas de segurança. Abaixo estão algumas sugestões:

Ferramentas Recomendadas para Testes de Segurança

1. Mozilla Observatory
   O Mozilla Observatory é uma ferramenta robusta que analisa configurações de segurança do seu site, incluindo cabeçalhos de segurança HTTP, HTTPS, CSP, HSTS e muito mais. Ele fornece pontuações e recomendações detalhadas para aprimorar a segurança.
   Acesse aqui
2. Security Headers
   Este serviço gratuito permite testar rapidamente os cabeçalhos de segurança do seu site, como X-Content-Type-Options, X-Frame-Options, e Content-Security-Policy. Ele destaca configurações ausentes ou mal configuradas e sugere melhorias.
   Acesse aqui
3. SERPWorx Security Headers Checker
   Uma alternativa que também verifica a implementação de cabeçalhos de segurança no seu site, fornecendo informações claras e práticas sobre o que está correto e o que precisa ser ajustado.
   Acesse aqui
4. SRI Hash Generator
   Se o site utiliza recursos externos, esta ferramenta gera hashes para implementar Subresource Integrity (SRI), garantindo que os arquivos carregados de CDNs não foram adulterados.
   Acesse aqui

Práticas Recomendadas para Testes Regulares

• Automatize verificações de segurança: Utilize ferramentas de integração contínua para rodar testes automatizados em todas as atualizações do site.
• Realize auditorias manuais: Complementar ferramentas automáticas com revisões humanas pode identificar problemas mais complexos.
• Eduque a equipe: Garanta que desenvolvedores e operadores entendam a importância das diretrizes de segurança e saibam como implementá-las.

Implementar essas medidas ajudará não apenas a proteger seus sistemas e usuários, mas também a construir uma reputação sólida no mercado como uma organização confiável e comprometida com a segurança. Use estas ferramentas regularmente para manter-se à frente das ameaças e para garantir que seu site continue seguro em um cenário de ameaças em constante evolução.