🚨 USOU VIBE CODING? TÁ CORRENDO RISCO | ENTENDA COMO

O cenário de risco no desenvolvimento com IA

O crescimento acelerado do desenvolvimento assistido por inteligência artificial, frequentemente chamado de vibe coding, tem permitido que produtos SaaS sejam lançados em velocidade recorde. No entanto, essa agilidade nem sempre vem acompanhada de maturidade em segurança. Muitos desenvolvedores partem do pressuposto de que as camadas de proteção estão ativas por padrão, quando na realidade a configuração padrão de diversas ferramentas e frameworks prioriza a facilidade de desenvolvimento em detrimento da robustez. A consequência é um cenário em que aplicações aparentemente funcionais escondem brechas graves, expostas a agentes externos que exploram justamente a falta de revisão crítica. O vídeo propõe uma análise direta sobre esse descompasso entre a velocidade de criação e a necessidade de blindagem. A premissa central é que a ausência de segurança não decorre necessariamente de incompetência técnica, mas de um ambiente que incentiva a entrega rápida e negligencia as validações estruturais. Ao longo dos dezoito minutos de conteúdo, o canal mano deyvin decompõe os principais vetores de ataque que afetam SaaS recém-lançados e sugere caminhos para uma auditoria realista e acessível.

Por que a segurança é deixada para depois

A pressão por lançamentos rápidos e a promessa de produtividade das ferramentas de IA criam um ambiente em que a segurança é tratada como etapa opcional. Em muitos casos, o desenvolvedor confia cegamente em bibliotecas e serviços gerenciados, sem verificar as políticas de acesso efetivamente aplicadas. O vídeo destaca que essa postura é agravada quando não há uma cultura de code review focada em vulnerabilidades. As brechas mais comuns em SaaS iniciantes raramente são sofisticadas; elas nascem de descuidos básicos que se acumulam silenciosamente. A falta de testes de invasão, a ausência de monitoramento de logs e a inexistência de um inventário de permissões transformam um produto funcional em um alvo fácil. O conteúdo também sugere que muitos programadores ignoram o impacto legal e reputacional de um vazamento, até que ele aconteça. É nesse vácuo de atenção que atacantes automatizados encontram espaço para operar, varrendo endpoints mal protegidos e explorando falhas conhecidas que já possuem exploit público. O recado é claro: não é questão de se a aplicação será atacada, mas de quando e com qual severidade.

Erros clássicos na exposição de dados

Entre os primeiros pontos discutidos estão os erros clássicos que expõem dados de usuários sem que o time perceba. Um dos equívocos mais frequentes é a exposição de chaves de API em repositórios públicos ou no front-end da aplicação. O vídeo menciona que ferramentas de varredura automatizada no GitHub e em outros serviços encontram essas credenciais em minutos, permitindo que terceiros consumam recursos ou acessem bases internas. Outro erro recorrente é a ausência de validação de entrada em formulários e endpoints, o que abre portas para injeção e manipulação de parâmetros. A confiança excessiva no cliente — como delegar filtros de acesso ao navegador — também aparece como falha crítica, pois qualquer usuário minimamente técnico consegue burlar essas verificações enviando requisições diretamente à API. O conteúdo reforça que esses problemas são amplificados em projetos criados com IA, porque o modelo gera código baseado em padrões genéricos encontrados na internet, muitos dos quais já nascem inadequados para produção. Sem uma revisão humana critériosa, o template inseguro se torna o alicerce do produto inteiro.

A armadilha do RLS desligado

Um dos tópicos centrais abordados é o RLS, sigla para Row Level Security, um recurso de segurança em bancos de dados relacionais, especialmente no Supabase e no PostgreSQL. Quando ele está desligado, qualquer cliente autenticado pode consultar tabelas inteiras, ignorando completamente as regras de negócio que deveriam limitar o acesso aos próprios registros. O vídeo alerta que a configuração padrão de muitos projetos não habilita o RLS, criando uma situação em que um usuário comum consegue listar dados de todos os outros clientes com uma simples chamada de API. Essa falha é particularmente perigosa em aplicações multitenant, onde a separação lógica entre contas é a única barreira entre um cliente e a base de dados de outro. A recomendação é habilitar o RLS por padrão e escrever políticas explícitas de leitura e escrita para cada tabela, testando o acesso com múltiplos perfis de usuário. O risco de ignorar essa configuração é imenso, pois a falha não éxige exploração complexa: basta uma requisição bem formada para vazar cadastros, documentos e informações sensíveis em massa.

O ataque IDOR em detalhes

O vídeo dedica uma parte considerável à explicação do ataque IDOR, do inglês Insecure Direct Object Reference. Esse tipo de vulnerabilidade ocorre quando a aplicação expõe referências diretas a objetos internos, como números sequênciais de registros, sem verificar se o usuário autenticado tem permissão para acessá-los. Em um SaaS, o exemplo clássico envolve um endpoint que retorna dados de uma fatura ou de um projeto com base em um ID na URL. Se a autorização estiver ausente, o atacante apenas incrementa o valor do identificador e acessa registros de terceiros. O IDOR é devastador porque costuma ser extremamente fácil de explorar e difícil de detectar por ferramentas básicas de varredura, já que não depende de payloads maliciosos complexos. O conteúdo enfatiza que a correção exige validação de posse do recurso no servidor, nunca no cliente, e que testes manuais com contas de baixo privilégio são o caminho mais eficaz para encontrá-lo. A falha é frequentemente subestimada justamente por não deixar rastros óbvios nos logs — o acesso indevido se parece com uma requisição legítima.

Auditoria prática e camadas de proteção

Depois de apresentar os principais vetores de ataque, o material avança para uma abordagem prática de auditoria. A proposta é que o desenvolvedor adote uma postura de atacante em relação ao próprio sistema, mapeando todos os endpoints, verificando políticas de acesso e testando combinações de permissões entre perfis diferentes. O vídeo sugere a criação de um checklist de verificação, cobrindo desde a exposição de segredos até a configuração de bancos de dados e o tratamento de erros. A camada de autenticação também recebe atenção, com alertas sobre o uso de tokens sem expiração adequada e a ausência de limite de tentativas de login. A recomendação central é implementar defesa em profundidade: mesmo que uma camada falhe, outras devem impedir o acesso indevido. Isso inclui autenticação robusta, autorização no servidor, criptografia em trânsito e em repouso, além de monitoramento contínuo de logs para detectar comportamentos anômalos. O conteúdo conclui que segurança não deve ser tratada como um recurso adicional, mas como parte estrutural do ciclo de desenvolvimento, presente desde o primeiro commit até a operação em produção.

O papel da comunidade e dos especialistas

Um aspecto complementar discutido no vídeo é a importância de buscar apoio especializado quando a complexidade ultrapassa a capacidade interna do time. O canal menciona a possibilidade de contratar pentesters e desenvolvedores seniores para executar revisões independentes, especialmente em produtos que já possuem usuários reais. A visão externa é valiosa porque identifica cegueiras que a equipe original, imersa no dia a dia do projeto, não énxerga. Além disso, a comunidade técnica desempenha papel relevante ao compartilhar relatos de incidentes e boas práticas, alimentando um ciclo de aprendizado contínuo. O apelo final do vídeo convida a audiência a refletir sobre a própria maturidade de segurança e a agir antes que um vazamento aconteça. A mensagem se conecta com a realidade brasileira de desenvolvimento, onde muitos SaaS são criados por equipes enxutas, com poucos recursos e alta pressão por resultado. Nesse contexto, investir algumas horas em auditoria e configuração correta vale muito mais do que énfrentar as consequências de uma violação de dados tornada pública.