Como um vibe coder descobre se o painel admin está exposto na internet

Uma auditoria de segurança pode aprovar o seu código inteiro e ainda deixar passar o risco mais urgente do sistema. Ela lê o repositório, e o que deixa um painel administrativo aberto para a internet não está no repositório: está em como o serviço foi publicado e em quem está na frente dele filtrando o que chega.

Danilix esbarrou nisso ao vivo, auditando o ERP de marketplace que constrói na live. Ele tinha motivo para caprichar: "Me preocupo bastante com a segurança dos meus clientes." O relatório voltou até bom, e a correção necessária que sobrou era o painel de administração respondendo direto na internet.

O mesmo relatório elogiou o código e reprovou o deploy

Poucas linhas antes do achado, a auditoria dava o veredito sobre o código:

"Código nasceu com uma boa postura de segurança para construir com autenticação global."

E então vinha a linha que ele leu em voz alta da tela:

"Pô, o risco imediato não está na lógica, está no [empacotamento] do deploy. O painel dash está publicado direto na internet puro furando [...] firewall."

A legenda automática da live escreveu "empapotamento", que é corrupção de empacotamento, e por isso a palavra vai entre colchetes. Logo antes de "firewall" a legenda engoliu alguma coisa e saiu ruído, sem como saber que palavra estava ali.

A reação dele foi imediata: "É isso, é verdade."

As duas linhas do relatório não se contradizem. O código pode exigir autenticação em toda rota e o deploy pode, ao mesmo tempo, ter publicado o serviço do painel num endereço que qualquer pessoa alcança. Autenticação é propriedade do código, alcance é propriedade do deploy, e o relatório só tinha lido o código.

Por que a auditoria que lê código não enxerga o painel aberto

O agente auditor lê arquivos. Ele consegue afirmar que existe middleware de autenticação e que a query filtra por cliente. Nenhum desses arquivos diz qual container ganhou endereço público, nem se a regra de firewall que deveria estar na frente do painel chegou a existir. Essas decisões moram no ambiente, e um relatório que nunca saiu do repositório está adivinhando sobre elas.

Na mesma leitura apareceu a prova disso. O relatório elogiava o webhook da Stripe com assinatura verificada, e Danilix respondeu que nem tinha conectado a Stripe ainda. O texto descrevia o código escrito, não o sistema no ar, e ele próprio já avisava: "O sinal não é uma prova."

Essa é a versão específica de uma distinção mais geral, entre o que falta de código e o que falta de configuração. Isso aparece também em react native vs flutter. Ali a separação servia para estimar prazo. Aqui ela decide quem consegue abrir o seu painel.

Como fazer essa checagem no seu projeto de vibe coding

A checagem se faz de fora da sua rede, porque de dentro tudo abre e isso não prova nada. Peça a alguém em outra conexão, ou use uma rede que não seja a do seu escritório, e tente chegar ao painel administrativo. Se a tela de login aparecer para essa pessoa, o painel está publicado na internet, e essa tela passou a ser a primeira barreira do sistema.

Depois descubra por qual endereço e por qual porta ele respondeu. Isso importa porque o painel pode estar publicado 2 vezes: uma pelo caminho que você conhece, passando pelo proxy, e outra pelo endereço direto da máquina ou do container, que ninguém lembra de fechar. O segundo caminho é o que fura o firewall, e ele existe quando o serviço abriu porta para fora em vez de abrir só para o proxy. Vá serviço por serviço e separe os que aceitam conexão de qualquer origem dos que só aceitam de quem já está do lado de dentro.

A terceira pergunta é a que o relatório do Danilix transformou em requisito escrito: "Nenhuma superfície administrativa acessível fora da TLS." Nada de administrativo pode responder por uma via sem TLS, nem mesmo para redirecionar. Isso vale para o painel principal e para o resto da superfície administrativa que você esqueceu que existe: a rota de métricas, o painel do banco, a fila, a ferramenta de admin que você subiu num sábado para conferir uma tabela.

No vibe coding essa checagem é a mais fácil de pular, porque quem subiu o serviço foi o comando que o agente sugeriu e você aprovou. A URL respondeu e o assunto morreu ali. Ninguém decidiu publicar o painel, ele foi publicado junto, como parte do pacote, e o único jeito de saber é olhar de fora depois que já está no ar. Rode essa volta a cada deploy que mexe em infraestrutura, e não a cada release de tela. Isso aparece também em vibe coding para nao oferecer gpu local se precisa de instalador. Isso aparece também em vibe coding para fundir cortes que se cruzam. Isso aparece também em totp.

Depois de descobrir, o problema muda de natureza

Achar o painel aberto resolve a parte difícil, que é enxergar. Fechar é trabalho conhecido: tirar o painel do endereço público e exigir um segundo fator para entrar são os 2 movimentos que outro builder detalhou em segurança de painel admin no vibe coding. Faça nessa ordem, porque blindar o login de um painel que continua respondendo por um segundo endereço aberto não muda quase nada. O mesmo problema apareceu em o que é white label.

Vale também olhar o relatório uma segunda vez procurando o que dá para prometer a cliente, que foi o que o Danilix fez com o isolamento entre clientes. A auditoria toda, com o relatório na tela e a leitura ao vivo, está em assistir à live.

Faça hoje a lista dos endereços pelos quais o seu sistema responde de fora e marque quais deles são administrativos. Quem faz vibe coding costuma achar essa lista maior do que imaginava, porque cada serviço que o agente subiu para resolver um problema pontual continuou no ar depois que o problema passou.