Teste de segurança para código escrito no Cursor

Com Cursor, o código é seu — mas a revisão de autorização não aconteceu. Testamos a API gerada para verificar se o que o modelo escreveu resiste a um atacante.

Em uma frase: Com Cursor, o código é seu, mas a autorização costuma ficar no componente — e o servidor aceita.

Por que isso acontece no Cursor

O Cursor acelera a escrita, mas não substitui a revisão. A autorização fica no componente, a validação fica no formulário e o servidor aceita o que vier.

O que costuma ficar aberto

1. Autorização no cliente. A checagem existe no front e desaparece na rota.
2. Segredo hardcoded. Chave de API commitada ou embutida no build.
3. Validação ausente no servidor. Payload inválido aceito e persistido.
4. IDOR em rotas CRUD. Trocar o ID retorna recurso de outro usuário.
5. Dependência inventada. Pacote sugerido pelo modelo que não existe no registro.

Exemplo real

Troca de ID devolve recurso de outro usuário

GET /api/users/42 HTTP/2
Authorization: Bearer <token da conta A>

200 · perfil da conta B

A conta A autentica normalmente, mas o servidor não confere o dono do objeto.

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.

Entram no escopo IDOR em rotas CRUD, mass assignment, segredos no build, dependência inexistente e CORS.

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. Crie duas contas com um recurso cada
2. Troque o ID do recurso na requisição
3. Envie campos extras no PATCH
4. Rode auditoria de dependências

O que o teste não cobre

• Não cobre arquitetura
• Não substitui teste de carga
• Não certifica conformidade

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

• A autorização existe no componente, não na rota.
• PATCH aceita campos que o formulário não mostra.
• Uma dependência entrou sem revisão.

Checklist rápido

• Auth no handler
• IDOR trocando o ID
• PATCH com role/plan
• Segredo no repositório
• Dependência inexistente
• Validação server-side

O que fazer agora

• Checar o dono do recurso em toda leitura e escrita.
• Validar payload com schema no servidor.
• Adicionar um teste de autorização por regra crítica.

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