Quase 1 milhão de documentos expostos: o risco de falhas básicas em APIs

O custo da negligência em APIs e buckets públicos

Recentemente, a segurança digital sofreu um golpe duro: quase um milhão de passaportes e documentos de identificação foram deixados expostos na internet pública. O caso envolve a empresa Cannabis Club Systems (CCS), também conhecida como Nefos, que fornece software para clubes de cannabis na Espanha. O incidente não foi fruto de um ataque complexo, mas de uma falha de design fundamental: documentos sensíveis estavam acessíveis via URLs públicas sem qualquer controle de autenticação ou autorização.

Para quem atua com desenvolvimento, operações ou gestão de produtos, este cenário é um lembrete pragmático sobre o que acontece quando a segurança é tratada como um detalhe acessório, e não como parte central da arquitetura. Como vimos em casos como a planilha de senhas, a falha humana e a negligência técnica formam um combo destrutivo para qualquer operação.

Como a falha foi descoberta

O pesquisador de segurança Sammy Azdoufal, ao analisar o aplicativo PuffPal (da Nefos), encontrou uma série de vulnerabilidades críticas. Primeiro, havia uma chave de API do Stripe exposta em texto plano dentro do código. Mais grave ainda: bastava alterar o ID do usuário em uma chamada de API para acessar perfis completos, incluindo endereços, números de telefone e documentos de identificação.

As imagens de passaportes e CNHs estavam armazenadas em URLs previsíveis, como /ID/{user_id}-front.jpg. O sistema permitia que qualquer pessoa com conhecimento básico de linha de comando extraísse dados sensíveis apenas disparando requisições curl para endpoints mal protegidos. O cenário é um exemplo clássico de falha em privacidade e controle de acesso que expõe dados de usuários de diversas nacionalidades, incluindo 30 mil cidadãos dos Estados Unidos.

O impacto da terceirização sem governança

A empresa Nefos atribuiu parte da responsabilidade à 9Series, firma de outsourcing que desenvolveu o app. Contudo, a lição para quem lidera times técnicos é clara: a responsabilidade final sobre o dado é sempre do dono da plataforma. Delegar o desenvolvimento de APIs críticas sem um processo rigoroso de auditoria de segurança e revisão de código é um convite ao desastre.

Mesmo após o primeiro alerta, a empresa tentou "tapar buracos" sem interromper o serviço, o que resultou em dados voltando a ficar expostos. A demora em seguir protocolos de notificação (como a obrigatoriedade de reporte em 72 horas exigida pela lei da UE) expõe a empresa a multas pesadas e danos irreparáveis à reputação.

O que muda na sua rotina de desenvolvimento

O caso Nefos reforça que segurança não é apenas sobre firewalls, mas sobre a lógica de acesso em cada endpoint. Algumas medidas práticas para evitar cenários similares:

• Validação de Autorização: Nunca confie que o ID do usuário na URL é suficiente. Sempre verifique se a sessão autenticada tem permissão para acessar aquele recurso específico.
• Auditoria de APIs: Tratamento de chaves de API (como Stripe ou AWS) deve ser feito via variáveis de ambiente ou gerenciadores de segredos, nunca em código versionado.
• Segurança por Design: Documentos sensíveis não devem ser servidos por URLs públicas. Utilize tokens de acesso temporários e assinados para servir arquivos privados.
• Cultura de Resiliência: Ferramentas como o Orqueza ajudam a centralizar a gestão de clientes e projetos, mas a responsabilidade de manter os dados seguros e bem estruturados dentro dessas plataformas e nos seus próprios fluxos é uma obrigação contínua de todo time de produto.

A lição final é que a "facilidade" de uso não pode atropelar a segurança. Se o seu sistema lida com dados sensíveis, a auditoria constante de endpoints e a segregação de permissões não são opcionais, são o básico.

Fonte: theverge.com