# Amostra de relatório de diagnóstico — Thorfyn

Canonical URL: https://thorfyn.com/pt/amostra-diagnostico

> Diagnóstico de exemplo de um app inventado feito com IA: achados do crítico ao baixo, evidência de antes e depois e uma decisão, endurecer ou reconstruir.

Exemplo: Exemplo · app inventado, não é um cliente real

O que o relatório diz sobre o seu app.

Um app inventado, gerado por IA, um marketplace de serviços. O relatório mostra o que encontramos, em que ordem corrigir e uma única recomendação.

## Achado 1 · crítico · o que vimos no app de exemplo

- Antes: GET /api/clientes (sem login) returned 200 OK
- Depois da correção: GET /api/clientes (sem login) returned 401 Unauthorized

Dados inventados. Qualquer pessoa, sem entrar, baixava a lista de clientes. Depois da regra de acesso, o mesmo pedido é recusado.

## Da mais grave à menos grave

6 achados, 8,5 dias de trabalho no exemplo. Abra um para ver o que vimos, o efeito e a correção.

1. **Tabelas legíveis sem entrar no app** (Crítico, 2 dias). O que vimos. A API pública devolve a lista de clientes sem nenhuma credencial. Efeito. Qualquer pessoa baixa dados pessoais de todos os clientes. Correção. Ligar regras de acesso por linha e testar com e sem login.
2. **Chave secreta de pagamento no código do navegador** (Alto, 1 dia). O que vimos. A chave aparece no pacote que o navegador baixa. Efeito. Quem abre o inspetor consegue usar a conta de pagamentos. Correção. Trocar a chave e mover a chamada para o servidor.
3. **Publicação direto em produção, sem teste** (Alto, 3 dias). O que vimos. Toda alteração do gerador vai ao ar na hora. Efeito. Um erro do gerador derruba o app para todos os clientes. Correção. Ambiente de teste, testes mínimos e aprovação antes de produção.
4. **Aviso de pagamento aceito sem conferir a assinatura** (Médio, 1 dia). O que vimos. O endereço que recebe o aviso aceita qualquer chamada. Efeito. Alguém pode marcar um pedido como pago sem pagar. Correção. Conferir a assinatura do provedor em cada aviso.
5. **Nenhuma cópia do banco que se consiga restaurar** (Médio, 1 dia). O que vimos. Não há cópia agendada nem teste de restauração. Efeito. Um erro de dados não tem volta. Correção. Cópia diária e uma restauração testada.
6. **Nenhum alerta se o app cair** (Baixo, 0,5 dia). O que vimos. Ninguém é avisado quando o app para. Efeito. O cliente descobre antes de você. Correção. Um verificador externo e um aviso por e-mail.

## Dois caminhos, uma escolha

A decisão é sua. O relatório recomenda um, por escrito.

- **Endurecer (Recomendado)** — Mantém a stack e fecha as falhas. A estrutura aguenta o produto de hoje; As falhas são de configuração, não de desenho; 8,5 dias de trabalho, no exemplo.
- **Reconstruir (Se mudar o produto)** — Muda para uma stack padrão, feita para chegar a um milhão de usuários. Faz sentido se a próxima funcionalidade exigir outro modelo de dados.

Por que o diagnóstico começa pelas regras de acesso: a CVE-2025-48757 registra apps gerados por um construtor de IA com tabelas do banco legíveis e graváveis sem login. O registro na NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-48757

## O seu diagnóstico, no seu app.

Uma semana de discovery, um relatório, uma recomendação.

- Ver a amostra do plano: https://thorfyn.com/pt/amostra-plano
- Dúvidas e pedidos: hello@thorfyn.com
- Voltar para a página inicial: https://thorfyn.com/pt