Acesso antecipado · ainda não está no ar
Publicou na sexta. No sábado alguém achou seu banco de dados.
O Doorknob testa cada porta do seu app publicado, do jeito que um curioso entediado com um navegador faria. Mostra o que está aberto, sem tecniquês, entrega o prompt exato pra colar no seu construtor e confere de novo toda vez que você clica em Publicar.
- Lovable
- Bolt
- Base44
- Replit
- v0
- CRÍTTabela profiles aberta pra qualquer um
1.204 linhas: email, full_name, phone. RLS desligado. Lemos 3 linhas pra confirmar e paramos.
- CRÍTChave da OpenAI indo pro navegador
/assets/index-8f2a.js · sk-proj-••••Qx7. Qualquer um usa, a fatura é sua.
- ALTO/admin abre sem login
A única checagem roda no navegador.
- MÉDCadastro aceita "role": "admin"
- OKSem chave service_role, HTTPS obrigatório
Ative o Row Level Security na tabela profiles. Crie políticas para que um usuário logado só consiga ler e editar a linha em que id = auth.uid(). Mova a chamada da OpenAI para uma Supabase Edge Function que lê a chave dos secrets e tire a chave de todo o código do front.
Por que isso existe
Como costuma acontecer.
Ninguém fez besteira aqui. O app fez exatamente o que foi pedido. Cada edição com IA é um deploy, e alguns deploys abrem uma porta sem fazer barulho.
- "Faz um app de hábitos com login e ranking."
- Funciona. E ficou bonito, viu.
- Mandou em três grupos do WhatsApp.
- "Faz o ranking mostrar a sequência de todo mundo."
- A IA afrouxa a política da tabela pro ranking ler todas as linhas. Inclusive os e-mails.
- Chega uma fatura da OpenAI que você não lembra de ter gerado.
Sábado, 10:31 é o minuto que importa. Ninguém repara nele.
Como funciona
Quatro passos. Um deles é provar que o app é seu.
A gente testa por fora, no app que os seus usuários acessam. Sem acesso ao código, sem SDK, nada pra instalar.
Cole a URL
Seu app no ar no lovable.app, bolt.new, base44, replit ou no seu domínio.
Prove que é seu
Um registro de DNS ou um arquivinho no site. Sem prova, sem teste.
A gente testa as portas
Tabelas abertas, chaves vazadas, login que só existe no navegador. Só leitura.
Confere a cada publicação
Todo deploy novo é testado. Se abrir uma porta, você recebe um e-mail.
O que testamos
As portas que a gente testa.
Cada uma é um erro fácil de cometer com construtor de IA, e das primeiras coisas que um atacante procura.
| ID | Teste | O que significa pra você |
|---|---|---|
| DK-01 | Tabelas abertas | Tabelas do Supabase ou Firebase que qualquer um lê ou escreve, porque o RLS está desligado ou frouxo demais. Os dados dos seus usuários, públicos. |
| DK-02 | Chave no front | OpenAI, Stripe, Resend e companhia dentro do JavaScript que todo visitante baixa. O uso é deles, a fatura é sua. |
| DK-03 | Login de mentirinha | Páginas e chamadas de API que deixam passar se você pedir direto. |
| DK-04 | Admin esquecido | /admin, /dashboard e rotas internas que dá pra achar no chute. |
| DK-05 | Cadastro confiante demais | Usuário que vira admin sozinho ou mexe na linha dos outros. |
| DK-06 | O que a última edição mudou | Cada teste é comparado com o anterior, então furo novo aparece na hora. |
Cada achado vem com uma ou duas frases sobre o que significa pros seus usuários e um prompt de correção escrito pro construtor que você usou. Se precisar clicar em algo no Supabase, a gente diz em qual botão.
Regras do jogo
Como a gente testa.
- Só testamos apps que você prova que são seus, com um registro de DNS ou um arquivo no site.
- Quando uma tabela está aberta, lemos o mínimo pra mostrar que está aberta e não guardamos as linhas.
- Nunca escrevemos, apagamos ou alteramos nada no seu app.
- Relatório limpo quer dizer que não achamos esses problemas. Não quer dizer que o app é perfeito, e a gente não vai fingir que é.
Testar o app dos outros sem pedir é o jeito mais rápido de virar assunto de outro tipo de relatório. Então a gente não faz, e ninguém faz pela gente.
Preço
Um plano só, enquanto a gente define.
Preço de acesso antecipado. Pode mudar antes do lançamento, e você fica sabendo antes de qualquer cobrança.
Primeiro teste grátis. Sem cartão pra entrar na lista. A ideia é aceitar Pix também.
- Teste completo do app no ar
- Novo teste a cada publicação
- Aviso por e-mail quando abrir alguma porta
- Prompts de correção pra Lovable, Bolt, Base44, Replit e v0
Sendo direto: o scanner está sendo construído agora. Entra na lista e o seu app vai na primeira leva. Quando chegar a sua vez, o relatório vai pro seu e-mail.
Você está na lista.
A gente te avisa por e-mail quando a sua leva abrir, já com o primeiro relatório. Antes de qualquer teste, vamos pedir pra você confirmar que o app é seu.
Por enquanto é só isso. Vai lá publicar alguma coisa.
Dúvidas
Perguntas justas.
Meu construtor já não tem checagem de segurança?
Alguns têm, e vale usar. A maioria lê o código. O Doorknob testa o app publicado por fora, que é onde um estranho de verdade vai estar, e repete depois de cada publicação.
Não sei programar. Vou entender o relatório?
A ideia é justamente essa. Cada achado é escrito pra quem fez o app conversando com ele, com um prompt pra colar de volta.
Isso é permitido?
Testar o seu próprio app, sim. Por isso a gente pede prova de que o app é seu antes de qualquer teste, e nunca altera nada nele.
O que vocês guardam?
Na lista de espera: nome, e-mail e URL do app, usados só pra falar com você sobre o acesso antecipado. Nos testes: os achados, não os dados dos seus usuários. Detalhes na política de privacidade.
Quando abre?
Ainda sem data. A primeira leva sai quando o scanner passar nos nossos próprios testes. A ordem da lista decide quem vai primeiro.