Diagnóstico para desenvolvedores

Como diagnosticar JSON, Base64 e JWT sem expor segredos

Separe erros de sintaxe, codificação e token, inspecione dados localmente e crie uma reprodução segura de falhas de API.

Em resumo

JSON é formato de dados, Base64 é codificação e JWT é um formato estruturado de token. Tratar os três como equivalentes gera conclusões erradas e exposição acidental. Identifique a camada que falhou, use amostras sanitizadas e lembre que decodificar um token não verifica sua assinatura.

  • Valide a sintaxe JSON antes do contrato da API.
  • Base64 muda a representação; não é criptografia.
  • Decodifique JWT apenas com amostras sanitizadas ou de teste.
  • Confira tempo, emissor, audiência e algoritmo além da assinatura.
  • Compartilhe a menor reprodução possível, sem segredos.

1. Identifique a camada que falhou

Separe transporte, HTTP, encoding de texto, parsing JSON, validação de schema, autenticação e regra de aplicação. Resposta 401 não é erro de sintaxe JSON, e documento JSON válido ainda pode violar o contrato do endpoint.

Registre método, formato do endpoint público, status, content type e corpo sanitizado. Remova Authorization, cookies, chaves e dados pessoais de screenshots, tickets e formatadores externos.

  • Status HTTP e content type registrados
  • Headers sensíveis removidos
  • Estrutura do corpo preservada
  • Schema ou contrato esperado disponível

2. Valide JSON com precisão

JSON aceita objetos, arrays, strings, números, booleanos e null. Nomes usam aspas duplas; comentários e vírgulas finais não fazem parte do JSON padrão. Um formatador aponta a posição do erro, mas não decide se o significado do campo está correto.

Observe números além da faixa inteira segura da linguagem, datas sem fuso acordado e strings que contêm um segundo JSON escapado. Compare payload conhecido com o defeituoso após normalizar a formatação.

3. Trate Base64 como codificação de transporte

Base64 representa bytes com caracteres imprimíveis. Quem recebe normalmente pode decodificar, portanto nunca use como proteção de senha. Base64 padrão e URL-safe mudam caracteres e regras de padding.

Descubra o encoding original antes de interpretar os bytes. Uma decodificação correta ainda pode parecer ilegível se os bytes estiverem comprimidos, criptografados ou não forem texto UTF-8.

  • Variante padrão ou URL-safe identificada
  • Padding tratado conscientemente
  • Encoding original conhecido
  • Resultado tratado como potencialmente sensível

4. Inspecione JWT sem confiar automaticamente

Um JWT compacto geralmente possui header, payload e assinatura. Os dois primeiros são codificados, não confidenciais. Decodificar revela claims, mas não prova quem criou nem se o token foi alterado.

A verificação deve impor algoritmo e chave esperados e validar emissor, audiência, expiração, not-before e regras da aplicação. Não aceite algoritmo apenas porque o token pediu. Evite colar bearer tokens reais em sites terceiros: a posse pode conceder acesso.

5. Monte uma reprodução segura

Troque identificadores por valores sintéticos preservando tipos, níveis e condições de borda. Reduza a requisição até uma diferença explicar a falha. Inclua status esperado, status real e trecho relevante da resposta.

Repita localmente ou em ambiente de teste aprovado. Se precisar de token, emita credencial curta e com escopo mínimo. Revogue credenciais expostas imediatamente; apagar uma mensagem não remove todas as cópias.

Próximo passo

Verifique o seu caso

Perguntas frequentes

JSON válido é automaticamente seguro?

Não. Pode conter segredos, strings maliciosas, aninhamento excessivo ou valores contrários ao contrato.

Base64 consegue esconder senha?

Não. É facilmente reversível. Use criptografia e armazenamento de segredos aprovados.

Posso confiar nos claims depois de decodificar JWT?

Não. Só depois da verificação criptográfica e da validação de emissor, audiência, tempo e regras da aplicação.

O que deve entrar no relatório de bug?

Requisição mínima sanitizada, esperado, status/corpo real, ambiente e passos reproduzíveis—nunca credenciais reais.

Fontes primárias e referência

Fontes consultadas na revisão editorial. Links externos abrem a publicação responsável pelo padrão ou orientação.