Existe uma classe de ferramentas online que, na superfície, parece inofensiva: geradores de hash, verificadores de integridade, calculadoras de checksum. Você cola um texto ou uma senha, clica em "Gerar", recebe o hash. O problema não está no resultado — está em onde o cálculo acontece.

Quando uma ferramenta de hash processa seu input em um servidor remoto, ela necessariamente recebe o dado original antes de retornar o hash. Para textos triviais — um slug de URL, um título de artigo — isso é irrelevante. Para qualquer dado que contenha informação sensível, é um vetor de exposição que a maioria dos desenvolvedores não considera até que seja tarde demais.

O Modelo de Ameaça que Ninguém Explica

Desenvolvedores experientes pensam em termos de superfície de ataque. Uma superfície de ataque é o conjunto de pontos onde um adversário pode tentar inserir, extrair ou manipular dados em um sistema. Cada vez que um dado sensível trafega pela rede — mesmo por HTTPS — ele passa por mais pontos de exposição potencial:

  • O servidor da ferramenta (que pode ser comprometido, ou cujo operador pode ter acesso aos logs)
  • Infraestrutura de CDN entre o cliente e o servidor
  • Qualquer middleware de inspeção de pacotes na rede corporativa do usuário
  • Logs de requisição no servidor (que frequentemente armazenam o body da requisição em modo debug)

HTTPS protege o dado em trânsito entre o cliente e o servidor da ferramenta. Não protege o dado depois que ele chega ao servidor. E não há como um usuário externo verificar o que o operador da ferramenta faz com o que recebe.

A Web Crypto API: Hash no Navegador sem Concessão de Performance

A objeção mais comum a ferramentas client-side é performance: "JavaScript é lento demais para criptografia". Essa objeção era válida em 2010. Em 2025, ela está factualmente errada.

A Web Crypto API — disponível em todos os navegadores modernos desde 2014, com suporte completo desde 2017 — expõe operações criptográficas implementadas em código nativo do browser, não em JavaScript puro. A função crypto.subtle.digest() executa SHA-256, SHA-384 e SHA-512 usando as instruções de hardware do processador (SHA-NI em CPUs Intel/AMD modernas, equivalente em ARM), com throughput comparável a implementações em C.

Na prática, um hash SHA-256 de uma string de 1KB executa em menos de 1 milissegundo no Chrome em um laptop de gama média de 2022. A latência de rede para uma requisição a um servidor remoto — mesmo em conexão de fibra — é de 20 a 100 milissegundos. A ferramenta client-side é ordens de magnitude mais rápida, não mais lenta.

O Que Pode e o Que Não Pode Ser Feito Client-Side

Nem todos os algoritmos de hash são implementáveis no browser com Web Crypto API. É importante entender as fronteiras:

Disponível nativamente via Web Crypto

  • SHA-256 — padrão atual para integridade de arquivos, assinaturas digitais e a maioria dos protocolos modernos
  • SHA-384 / SHA-512 — variantes de maior segurança da família SHA-2, recomendadas para dados de alta sensibilidade
  • SHA-1 — disponível, mas considere depreciado para qualquer uso de segurança

Não disponível via Web Crypto — requer servidor ou biblioteca JS

  • MD5 — excluído da Web Crypto por ser considerado inseguro para uso criptográfico (mas ainda usado para checksums não-criptográficos)
  • Bcrypt — algoritmo de hash de senhas com fator de custo adaptativo. Não existe implementação nativa no browser; requer servidor PHP/Node ou biblioteca JavaScript (que por sua vez simula as operações em JS puro, com performance reduzida)
  • Argon2 — vencedor da Password Hashing Competition, recomendado atual para hash de senhas. Não há implementação Web Crypto; requer backend
  • scrypt — alternativa ao bcrypt, sem suporte nativo em browsers

A distinção crítica: hashes de propósito geral (SHA-256, SHA-512) são seguros client-side com Web Crypto. Hashes de senhas (bcrypt, Argon2) requerem backend — e quando esse backend é seu próprio servidor (que você controla e audita), não um serviço de terceiro aleatório na internet, a superfície de ataque é gerenciável.

Por Que Isso Importa para Times de Desenvolvimento

O cenário mais comum de exposição inadvertida não é um desenvolvedor mal-intencionado. É o processo de onboarding de um desenvolvedor júnior que não conhece alternativas seguras e simplesmente googla "gerar hash SHA-256 online" quando precisa verificar um checksum durante um debug. Ele não vai usar a ferramenta para dados críticos — ou pelo menos não tem essa intenção. Mas o hábito se instala, e em algum momento um dado que não deveria trafegar para fora do ambiente corporativo vai trafegar.

Times sérios documentam explicitamente em seus guias de engenharia quais categorias de ferramentas externas são aceitáveis e quais não são. Ferramentas de hash que processam server-side geralmente entram na categoria "não aceitável para qualquer input que possa conter PII ou credenciais".

O Padrão de Implementação com Web Crypto API

Para desenvolvedores que precisam implementar hash client-side em seus próprios projetos, o padrão com Web Crypto API é direto:

async function sha256(message) {
    const msgBuffer = new TextEncoder().encode(message);
    const hashBuffer = await crypto.subtle.digest('SHA-256', msgBuffer);
    const hashArray = Array.from(new Uint8Array(hashBuffer));
    return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}

A função é assíncrona (retorna uma Promise), opera inteiramente na memória do browser sem qualquer comunicação de rede, e usa a implementação nativa do motor JavaScript — não uma biblioteca de terceiros que você precisaria auditar. O Gerador de Hashes desta coleção usa exatamente esse padrão para SHA-256.

Para MD5 e Bcrypt, onde Web Crypto não está disponível, a alternativa segura é um endpoint em seu próprio servidor — controlado, auditável e isolado do ambiente de produção — não uma ferramenta pública de terceiro.