\

Imagina que você abre a tela de Pagamentos, clica em excluir um lançamento duplicado, e o sistema não reclama de nada. Sem mensagem de erro, sem tela travada. Você segue pra próxima tarefa, achando que resolveu. Só que, se você voltasse e desse um refresh na página, o lançamento continuaria ali — porque a exclusão nunca chegou a acontecer. O sistema disse "ok" pra uma ação que ele nem tentou executar.

Foi exatamente esse tipo de falha que uma auditoria de segurança encontrou em 8 rotas da API do igency, e que já foi corrigida. Vale explicar o que aconteceu e por que esse tipo específico de bug é mais perigoso do que parece.

Por que um erro sincero é melhor que um sucesso mentiroso

Todo software tem bug. A diferença que importa é como o sistema se comporta quando algo dá errado. Duas respostas possíveis pra uma requisição que não pôde ser processada:

• Devolver um erro claro. Frustrante na hora, mas honesto — você sabe que precisa tentar de novo, ou que algo está errado, e pode agir em cima disso.
• Devolver sucesso mesmo sem ter feito nada. Parece "mais gentil" na hora, mas é o pior cenário: você segue confiando numa mudança que nunca existiu, e só vai descobrir o problema quando o dado errado aparecer em outro lugar — um relatório pro cliente com um lançamento que devia ter sido apagado, uma tarefa "concluída" que nunca foi marcada de verdade.

Um erro custa um clique extra. Um sucesso falso custa a confiança de que o sistema faz o que diz que faz — e essa é a base de qualquer ferramenta que lida com dado financeiro ou com o relacionamento com o cliente de alguém.

O que aconteceu, em termos simples

Rotas de API como "excluir tarefa", "editar cliente" ou "aprovar carrossel" recebem um identificador (o id do registro, ou o token de um link público) como parte do endereço da requisição. Existe um caso legítimo em que essa rota é chamada durante o processo interno de build do site, antes de qualquer usuário existir — e, pra esse caso específico, é normal responder sucesso genérico sem processar nada.

O problema é que um segundo guard, criado pra proteger contra um id vazio ou malformado (chegando, por exemplo, com o caractere [ literal, sinal de que o identificador não foi preenchido corretamente antes da requisição sair), usava a mesma resposta de sucesso do caso de build — em vez de tratar como o que realmente é: uma requisição que não pôde ser identificada e, portanto, não foi executada. Na prática, um DELETE com id malformado respondia "200, deu certo" sem apagar nada, e não tinha como o app que fez a chamada perceber a diferença entre "deu certo de verdade" e "não fiz nada, mas disse que fiz".

Eram 8 rotas nesse mesmo padrão — exclusão e edição de tarefa, marcar/desmarcar tarefa concluída, edição de cliente, geração de link de aprovação, exclusão de pagamento, edição de despesa e o próprio link público de aprovação de conteúdo que o cliente final usa.

Como o igency garante que "excluído" significa excluído, na prática

A correção trocou a resposta desse guard: em vez de {ok: true} com status 200, as 8 rotas agora devolvem status 400 com {error: "ID inválido"} (ou {error: "Token inválido"} no link de aprovação) sempre que a requisição chega sem conseguir identificar o registro. Isso vale hoje pra qualquer exclusão ou edição feita no painel — clientes, tarefas, pagamentos, despesas — e também pro link público que o cliente usa pra aprovar conteúdo.

Esse conserto soma com outra camada que já existia antes: toda rota de exclusão/edição no igency confere sessão de login e confirma que o registro pertence mesmo à conta de quem está pedindo, antes de tocar o banco — então mesmo com o identificador correto, uma tentativa de mexer no dado de outra conta já era barrada. O guard corrigido fecha a lacuna que sobrava antes mesmo dessa checagem: agora, se a identificação falhar, o sistema fala isso claramente, em vez de responder como se tivesse dado certo.

Vale mencionar também que, pra tarefas especificamente, "excluir" no igency nunca apaga o registro na hora — vira um soft-delete que some do Kanban e do link do cliente, mas continua recuperável na aba de tarefas arquivadas. Combinado com a resposta correta de erro, isso reduz ainda mais o espaço pra um clique em "excluir" resultar numa surpresa mais tarde, seja por um bug de identificação ou por engano do próprio uso.

Testando na prática

O plano Free do igency não pede cartão: até 3 clientes, Kanban de tarefas e aprovação de conteúdo por link, sem custo. A partir disso, o Pro custa R$19,90/mês (ou R$199/ano), com 30 dias de teste antes da primeira cobrança. Se sua agência já confia dado real de cliente e de pagamento numa ferramenta, vale saber que ela é auditada continuamente pra que "deu certo" signifique, de fato, que deu certo.

Criar conta grátis no igency →