Ia compartilhar um workflow n8n com a comunidade e quase mandei junto a chave da API

Antes de exportar um workflow meu pra compartilhar com a comunidade, abri o JSON pra dar uma olhada geral no que ia sair. Um dos nodes era HTTP Request, chamando uma API externa. O token de autenticação não estava num node de credencial do n8n. Estava colado direto no body da requisição, um dos campos do JSON que o node manda, texto puro, sentado no meio do workflow exportado.

A maioria exporta e manda sem abrir o arquivo antes — pra postar num fórum, mandar num grupo, ou vender. Se eu tivesse feito isso, quem baixasse esse workflow levava junto acesso à minha conta na API. Não achei porque o n8n avisou. Achei porque abri o JSON com a intenção específica de olhar antes de soltar.

Por que o node de credencial não resolve sozinho

O n8n tem um sistema de credenciais pra isso — você cadastra a chave uma vez, o node referencia por nome, o valor nunca aparece no JSON exportado. Funciona bem quando você usa. O problema é o atalho: pra uma API que só uso uma vez, ou uma chamada que montei rápido testando, é mais fácil colar o token direto num campo do body do que cadastrar uma credencial nova. Faz sentido enquanto o workflow é só meu. Vira vazamento no dia em que ele sai da minha conta.

E isso não aparece revisando visualmente o canvas. O campo do body mostra o valor preenchido do mesmo jeito que mostraria qualquer outro dado do payload. Só fica óbvio abrindo o JSON e lendo o parâmetro puro, porque na UI não salta aos olhos que aquele campo específico é uma credencial e não um dado comum da requisição.

O checklist que separei

Antes de compartilhar ou vender um workflow, dois blocos de segurança:

• 1.Credencial em texto puro. Varrer todos os nodes HTTP/webhook/código procurando valor de auth colado direto — header, query param, campo do body — em vez de referência a uma credencial cadastrada. Cada ocorrência vira decisão: essa chave devia estar aqui, ou o node devia usar credencial nativa e receber um placeholder no lugar? Esse item eu não deixo pra revisão manual: construí uma ferramenta que cola o JSON e varre por padrão de credencial conhecido (Bearer, chave da OpenAI/AWS/Stripe/GitHub, string de conexão de banco) em vez de depender de eu lembrar de abrir o arquivo antes de exportar, como fiz dessa vez. Ela detecta pelo formato do valor, não por adivinhação: um token genérico sem prefixo reconhecível passa despercebido, então a varredura reduz o trabalho de revisão manual, não substitui abrir o JSON de vez em quando.
• 2.Segurança do trigger. Se o workflow expõe um webhook, ele herda o que estiver configurado — ou não — nele: autenticação exigida, limite de taxa, validação do formato do payload aceito. Um workflow que roda liso na minha conta porque só eu chamo o webhook pode estar completamente aberto pra quem mais descobrir a URL. Esse item ainda é revisão manual: depende do tipo de trigger e do que a instância de destino já tem configurado, não dá pra inferir só olhando o JSON.

Fora do escopo de segurança, mas no mesmo momento de revisão antes de soltar o workflow, fica documentar o que é implícito no meu ambiente: variável de ambiente específica, versão de API, formato de payload que só existe no meu setup. Sem isso escrito, quem compra recebe um workflow que quebra silenciosamente fora do meu ambiente e lê isso como bug de qualidade, não como falta de contexto. Não é vazamento, é decepção. Mas os dois nascem do mesmo hábito de nunca ter revisado o workflow com outro olho além do meu.

O que fica

Compartilhar ou vender um workflow n8n é publicar um JSON que carrega tudo que você colou nele enquanto construía sozinho, sem plateia. O sistema de credenciais do n8n só protege o que passa por ele, não avisa sobre o atalho que você tomou numa chamada de teste e esqueceu de arrumar. Revisar antes de soltar não é excesso de cuidado, é a única etapa que existe entre “funciona na minha conta” e “vazou pra quem comprou”.