Teste de segurança para código gerado com Ollama

Modelos locais via Ollama são ótimos para prototipar rápido. Segurança não é o padrão que eles aprendem sozinhos — o código gerado precisa da mesma revisão ou de teste.

Em uma frase: Modelo local resolve custo, não autorização: a API gerada precisa da mesma revisão.

Por que isso acontece no Ollama

Rodar o modelo na sua máquina resolve custo e privacidade, não autorização. O código gerado segue o mesmo padrão: funciona na tela e deixa a API aberta.

O que costuma ficar aberto

1. API sem autenticação. O endpoint responde sem sessão.
2. Banco exposto pelo front. Consulta direta com a chave pública.
3. CORS com credenciais. Origem hostil lê resposta autenticada.
4. Segredo em arquivo local. Chave em .env, script ou bundle.
5. Sem rate limit. Consumo e força bruta sem bloqueio.

Exemplo real

Dados servidos sem cookie

GET /api/items HTTP/2
(sem cookie)

200 · itens com dono e e-mail

O app foi gerado localmente e publicado; a rota de dados nunca verificou sessão.

O que testamos

Vinte verificações: OWASP API Top 10 aplicado ao stack, mais configuração de banco, segredos no bundle, sourcemaps, CORS, rotas de debug e limite de uso. Onze rodam automatizadas; as demais entram na revisão manual de autorização.

O teste cobre rotas sem sessão, banco acessível pela chave do front, CORS, sourcemaps, segredos em arquivos locais e limite de uso.

Como o laudo trata esse achado

A evidência entra com método, caminho e resposta redigida; a severidade considera o que um atacante obtém sem credencial; a correção é escrita para o seu stack, não como aviso genérico. O que não conseguimos reproduzir fica fora do laudo.

Como testar em 10 minutos

1. Copie a chave do bundle
2. Consulte o banco com ela
3. Chame a API sem cookie
4. Dispare 20 requisições

O que o teste não cobre

• Não avalia o modelo local
• Não substitui revisão de código
• Não garante ausência de falhas

Como funciona

1. Call de 15 minutos para fechar escopo, alvo e autorização.
2. Proposta com valor e prazo em 24h.
3. Teste em 48h, com laudo e correção escrita.

Sinais de que você precisa

• O app foi gerado com modelo local e publicado direto.
• A chave do banco está no JavaScript.
• Nenhuma rota tem teste de autorização.

Checklist rápido

• Rota sem sessão
• Chave no JavaScript
• CORS com credenciais
• Validação server-side
• Dependências
• Rate limit

O que fazer agora

• Exigir sessão em toda rota que devolve dado.
• Tirar a chave do front e rotacionar.
• Aplicar rate limit e validar no servidor.

Veja também todas as verificações e o checklist de 12 itens.