Existe uma narrativa crescente de que o ‘Vibe Coding’ está destruindo a segurança do software, facilitando o vazamento de chaves e credenciais sensíveis. Mas, será que estamos olhando para o culpado certo?
Se voltarmos no tempo, para uma era pré-2020, veremos que o cenário de Bug Bounty já estava repleto de falhas críticas de exposição de chaves de API. O erro de ‘commitar’ um arquivo .env ou deixar uma chave de AWS em um repositório público não é uma invenção da IA generativa; é um desafio clássico de engenharia que nos persegue há décadas.
Para fundamentar essa análise técnica, e seguindo rigorosamente os parâmetros de análise de metadados do meu modelo de estudo, selecionei 10 casos da plataforma HackerOne que provam: a segurança básica sempre foi (e continua sendo) um desafio humano.
1. Starbucks: Chave de API JumpCloud no GitHub (2019)
Um dos casos mais famosos. Um pesquisador encontrou uma chave de API da JumpCloud em um repositório público da Starbucks. Isso dava acesso a sistemas internos e informações de usuários.
- Link: HackerOne #716292
- Data: Outubro de 2019
2. Twitter: Exposição de Chaves de API e Senhas do Jira (2017)
O domínio cards-dev.twitter.com estava com uma diretiva de listagem de diretório aberta, permitindo o download de um arquivo json.json que continha customer_key, customer_secret e até a senha do Jira da equipe.
- Link: HackerOne #268888
- Data: Setembro de 2017
3. Slack: Tokens expostos via Engenharia Reversa (2018)
Embora o relatório envolva a Grab (empresa de transporte), o alvo foi o Slack da empresa. O pesquisador baixou um app Electron e, ao fazer engenharia reversa, encontrou tokens xoxp que davam acesso total a todos os canais do Slack da organização.
- Link: HackerOne #397527
- Data: Agosto de 2018
4. Snapchat: Token do GitHub exposto (2018)
O Snapchat teve um token do GitHub exposto publicamente, o que poderia permitir o acesso a repositórios privados da empresa.
- Link: HackerOne #396467
- Data: Agosto de 2018
5. Uber: Bucket S3 Aberto com Documentos Confidenciais (2018)
Embora focado em um bucket S3, este caso demonstra a falha clássica de deixar credenciais e caminhos de infraestrutura expostos em microsites da empresa.
- Link: HackerOne #361438
- Data: Junho de 2018
6. Twitter: Chaves Oficiais Vazadas em apps (2013/2018)
Este relatório discute como chaves oficiais do Twitter (para iPhone, Android) foram vazadas e usadas para criar apps de terceiros que enganavam usuários sobre permissões de DMs.
- Link: HackerOne #434763
- Data: Outubro de 2018 (Discussão de chaves vazadas anteriormente)
7. Snapchat: API de Kubernetes Exposta (2018)
Exposição de um endpoint de API do Kubernetes sem autenticação, permitindo a execução de código e acesso a credenciais internas.
- Link: HackerOne #455645
- Data: Dezembro de 2018
8. Slack: Exportação de dados via S3 previsível (2014)
Um erro de lógica na API permitia que qualquer um previsse URLs de exportação de dados armazenados no S3 devido à falta de autenticação robusta no link gerado.
- Link: HackerOne #2746
- Data: Março de 2014
9. Omise: Chaves Secretas no GitHub (2019)
Exposição de chaves públicas e secretas em um repositório da própria empresa (Omise), permitindo manipulação de contas e visualização de saldos.
- Link: HackerOne #508024
- Data: Março de 2019
10. Valve (Steam): API Key do Steamworks exposta (2016/2017)
Embora muitos relatórios da Valve sejam privados, houve casos documentados de exposição de chaves que permitiam manipular inventários e dados de jogos. Um exemplo de exposição de informações sensíveis pode ser visto em relatórios como o abaixo:
- Link Relacionado: HackerOne #153125 (Exemplo de vazamento de informações de apps/chaves).
Por que isso acontecia antes do “Vibe Coding”?
Muitos argumentam que a IA hoje escreve código sem contexto de segurança, mas os relatórios acima provam que os padrões de erro eram os mesmos:
- Hardcoding: Desenvolvedores inseriam chaves diretamente no código para testar rápido (“vibe” manual) e esqueciam de remover.
- Configurações de Git: O
.gitignoreera mal configurado, enviando pastas como.envouconfig/para o GitHub. - Logs de Debug: Chaves eram impressas em logs de erro que acabavam sendo indexados por motores de busca.
Como encontrar esses relatórios na íntegra?
Você pode acessar a plataforma HackerOne (H1) e usar filtros de busca específicos para estudar os write-ups detalhados. Use os seguintes termos de busca no diretório de atividades:
"API Key exposed""AWS Secret Access Key""Hardcoded credentials"
Finalizando
Costumo brincar que, após o surgimento do RaaS (Ransomware as a Service), enfrentamos agora o perigo do VaaS: Vulnerability as a Service (aquele código gerado puramente no ‘vibe coding’), sem revisão ou contexto. No entanto, minha visão profissional é otimista. Se por um lado as IAs facilitam levar projetos do papel à produção com falhas de segurança, por outro, elas nunca tornaram tão fácil a tarefa de identificar e corrigir esses mesmos erros. Estamos vivendo uma era onde estudar, pesquisar e remediar vulnerabilidades tornou-se mais acessível do que em qualquer outro momento da história da computação
