← Todos os artigos
Atualizado em May 29, 20267 min read

Por que você não deve colar JSON sensível em ferramentas online

Tokens JWT, chaves de API, PII e exports de banco de dados são rotineiramente colados em formatadores online. Eis o que acontece com esses dados do lado do servidor — e por que ferramentas nativas do navegador são a escolha mais segura.

Um desenvolvedor esbarra num erro de parse, copia o JSON da resposta da API e cola no primeiro formatador online que aparece no Google. O JSON contém IDs de usuário, endereços de e-mail, tokens de sessão ou um arquivo de configuração interno. Isso acontece dezenas de vezes por dia em todo time de engenharia. Este artigo explica exatamente que riscos isso cria —— e por que uma ferramenta nativa do navegador os elimina.

Que tipo de dados acaba em ferramentas JSON online

Na prática, desenvolvedores colam o que estiver causando o problema imediato. Isso significa:

  • Tokens JWT —— contêm claims de identidade do usuário, papéis e expiração. A assinatura impede adulteração, mas o payload é texto puro codificado em Base64url: qualquer pessoa que logue seu token consegue ler cada campo dele.
  • Respostas de API com PII —— nomes, e-mails, telefones, datas de nascimento, endereços. Uma única página de resultados de busca de uma API voltada ao cliente pode conter centenas de registros.
  • Arquivos de configuração —— connection strings de banco, API keys de terceiros, configurações de feature flag, URLs de serviços internos.
  • Exports de banco de dados —— dumps JSON de tabelas inteiras, às vezes gerados para debug e colados como estão.
  • Dados de negócio internos —— regras de precificação, termos de contrato, dados de produtos não lançados que não têm classificação pública mas ainda são sensíveis.

Nada disso parece sensível no momento. O desenvolvedor quer entender a estrutura, não compartilhar dados. Mas colar isso numa ferramenta online é indistinguível de mandar para um terceiro.

O que acontece quando você envia dados para uma ferramenta online

A maioria dos formatadores, validadores e ferramentas de diff online funcionam mandando sua entrada para um endpoint de servidor, processando lá e devolvendo o resultado. Mesmo ferramentas que dizem ser «client-side» às vezes mandam dados para logging, analytics ou rastreamento de erro. Eis o que pode acontecer com os dados nesse caminho.

Logging do lado servidor

Servidores web logam request bodies por padrão em muitos frameworks. Um único POST do seu payload JSON pode acabar em:

  • Logs de aplicação armazenados em disco ou num serviço de logging (Datadog, Splunk, CloudWatch)
  • Ferramentas de rastreio de erro (Sentry, Bugsnag) —— especialmente se o parse falhar
  • Uma linha de banco numa tabela de «analytics» ou «usage»
  • Logs de acesso de CDN ou load balancer que o operador da ferramenta pode nem monitorar

Políticas de retenção de log variam bastante. Algumas ferramentas guardam logs por 90 dias; outras guardam indefinidamente. Em qualquer caso, o operador —— e qualquer um que tenha acesso aos sistemas dele —— pode ler o que você enviou.

Analytics de terceiros

Muitas ferramentas online incluem JavaScript de terceiros para analytics ou publicidade. Esses scripts conseguem observar requisições de rede, envios de form e eventos de input. Se a ferramenta manda seus dados para o servidor dela, a camada de analytics também enxerga a transação HTTP.

Cache e armazenamento em CDN

Algumas ferramentas cacheam resultados pela chave do conteúdo de entrada. Se dois usuários enviam o mesmo JSON, o segundo recebe uma resposta cacheada. A entrada pode ficar no cache por horas ou dias. Em casos extremos, caches mal configurados deixaram envios de usuário publicamente acessíveis via uma URL previsível.

Indexação por mecanismos de busca

Formatadores que geram um permalink compartilhável (uma URL contendo ou referenciando seu JSON formatado) historicamente tiveram a saída crawleada por mecanismos de busca. Buscar uma string distintiva de um arquivo de config interno e achar ela num domínio de formatador JSON é uma experiência desconfortável.

Exposição regulatória

Se sua organização processa dados pessoais sob GDPR, HIPAA, CCPA ou frameworks similares, colar os dados de um usuário numa ferramenta online de terceiro pode constituir uma transferência de dados não autorizada —— mesmo se foi acidental e a ferramenta é respeitada. O framework não distingue entre compartilhamento intencional e escolhas de ferramenta descuidadas. A pergunta que ele faz é: dados pessoais saíram do limite de processamento autorizado?

Para entidades cobertas por HIPAA especificamente, mandar informação de saúde protegida para um serviço de terceiro que não assinou um Business Associate Agreement (BAA) é uma violação reportável, independentemente de os dados terem sido usados de forma indevida.

Como ferramentas nativas do navegador funcionam diferente

Navegadores modernos conseguem rodar lógica complexa —— parse, validação, diff, formatação, encoding —— totalmente dentro da engine JavaScript, sem precisar de requisição de rede. Uma ferramenta construída nesse modelo se comporta como uma aplicação local que por acaso é entregue pela web.

Quando você cola JSON numa ferramenta nativa do navegador:

  • O texto entra numa variável JavaScript na memória do seu navegador.
  • Um parser (também JavaScript) processa ele na mesma aba.
  • A saída é renderizada no DOM.
  • Nenhuma requisição HTTP é feita pra qualquer servidor com seus dados como payload.

Os dados nunca saem da sua máquina. Não podem ser logados, cacheados ou indexados porque nunca foram transmitidos.

Como verificar se uma ferramenta é mesmo local

Afirmações como «nunca armazenamos seus dados» são comuns e não dá para verificar de fora. A única checagem confiável é o painel Network do seu navegador:

  1. Abra o DevTools (F12 ou Cmd+Option+I).
  2. Vá na aba Network e marque Preserve log.
  3. Cole seu JSON na ferramenta e dispare a operação (formatar, validar, etc.).
  4. Filtre as requisições por XHR/Fetch. Se alguma requisição saindo carregar sua entrada como payload, a ferramenta não é client-side.

Uma ferramenta de verdade local não mostra nenhum POST ou fetch saindo com seus dados. Você pode ver requisições para assets estáticos (arquivos CSS, JS) ou pings de analytics, mas nenhuma vai conter seu payload JSON.

// O que uma ferramenta local faz —— sem chamada de rede:
const result = JSON.parse(userInput);   // roda no navegador
render(result);                         // atualiza o DOM

// O que uma ferramenta do lado servidor faz:
const res = await fetch('/api/format', {
  method: 'POST',
  body: JSON.stringify({ input: userInput }),  // seus dados saem da máquina
});

Padrões práticos: BAAs, WebCrypto e helpers de redação

Três padrões cobrem a maior parte do risco restante:

  • Business Associate Agreements (BAAs) para trabalho próximo de HIPAA —— se seu time lida com informação de saúde protegida, qualquer serviço de terceiro que encoste nela precisa de um BAA assinado em arquivo. Por isso colar PHI num formatador qualquer, mesmo um que «roda local», é tanto problema de documentação quanto técnico.
  • WebCrypto no client —— quando você de fato precisa fazer hash, assinar, criptografar ou gerar chaves no navegador, a API padrão crypto.subtle faz isso sem round-trip de servidor. É a primitiva certa para «descriptografar esse payload pra olhar» sem mandar o ciphertext pra lugar nenhum.
  • Helpers de redação —— para debugar, passe o JSON por um pequeno redator antes, que mascara valores em keys notoriamente sensíveis (password, token, email, ssn) antes de colar em qualquer lugar. Uma função de vinte linhas é melhor que descobrir tokens no log de requisição de uma ferramenta de analytics.

Políticas de time que valem a pena ter

Consciência individual só vai até certo ponto. Uma política leve cobre o vão:

  • Classifique antes de colar. Se o JSON contém nomes, e-mails, IDs, tokens ou chaves —— é sensível. Use uma ferramenta local ou uma interna aprovada.
  • Mantenha uma lista de ferramentas aprovadas. Uma lista curta de ferramentas verificadas como local-first é mais fácil de seguir do que uma regra genérica de «tome cuidado».
  • Nunca compartilhe credenciais de produção em sessões de debug. Rotacione qualquer token ou chave que tenha sido colada numa ferramenta online, mesmo se a ferramenta parece segura.
  • Use amostras saneadas para debug. Substitua valores reais de usuário por dados sintéticos antes de colar. Uma estrutura com "email": "test@example.com" é igualmente útil para debugar um erro de parse quanto o endereço real.

Perguntas frequentes

É seguro colar JSON sensível em ferramentas online?

Só se a ferramenta processar tudo no seu navegador. Formatadores do lado servidor podem logar, cachear ou indexar sua entrada —— e colar PII num terceiro pode em si violar GDPR ou HIPAA, independente da intenção.

Como verifico se uma ferramenta JSON roda local?

Abra o DevTools → Network, marque «Preserve log» e rode a operação. Se nenhuma requisição saindo carregar sua entrada como payload, a ferramenta é client-side. Requisições de assets estáticos e de analytics são tranquilas; um POST do seu JSON não é.

O que faço se eu já colei um token numa ferramenta online?

Rotacione. Trate qualquer credencial ou chave que tocou uma ferramenta de terceiro como comprometida, mesmo se a ferramenta parece respeitável. Lembre que um token codificado em Base64 ainda é texto puro.

Como meu time pode evitar isso de vez?

Use ferramentas nativas do navegador, mantenha uma lista de ferramentas aprovadas, e debugue com dados de amostra saneados ("email": "test@example.com") em vez de registros reais.

O que o fixjson.org faz

Toda ferramenta no fixjson.org —— reparo de JSON, JSON diff, formatador YAML, JSON Stringify, encode/decode Base64 e decode de URL —— roda inteiramente no seu navegador. O parser, a engine de diff e os formatadores são todos JavaScript executando localmente. Você pode verificar isso na aba Network: nenhuma requisição POST carrega sua entrada.

O site carrega assets estáticos (HTML, CSS, JS) uma vez de um CDN. Depois disso, funciona offline. Nenhuma entrada é mandada para nenhum servidor. Nenhum dado é logado, armazenado ou compartilhado.

  • JSON Fix —— repare e formate JSON inválido, no client
  • JSON Diff —— compare dois documentos JSON ou YAML, no client
  • Encode & Decode Base64 —— inspecione payloads JWT e data URIs sem mandar para lugar nenhum
  • URL Decode —— decode percent de query strings localmente
  • Base64 não é criptografia —— por que dados codificados ainda são legíveis por qualquer um que pegue a string