Durante o desenvolvimento do Templo Digital, meu projeto de hackathon (uma vitrine 3D de cursos construída com React, Vite e Three.js), passei por uma fase de hardening de segurança que não era estritamente necessária para o escopo do projeto. Afinal, não existem dados sensíveis ali, não há login, não há cartão de crédito, não há CPF. Só uma experiência imersiva e algumas chamadas simples de API.
Ainda assim, decidi tratar o projeto como se ele fosse crítico. Configurei headers de CSP no vercel.json, corrigi uma CVE conhecida do Vite e documentei cada decisão. O motivo é simples. Quem pretende atuar com fintech não pode aprender segurança só quando o problema aparece em produção com dinheiro real envolvido.
Por que praticar segurança mesmo sem dados sensíveis
Aplicações financeiras têm uma característica que as diferencia de qualquer outro tipo de sistema. Um bug em uma vitrine de cursos gera um print de erro constrangedor. Um bug equivalente em um sistema de pagamentos gera prejuízo real, exposição de dados e, dependendo da gravidade, consequências legais.
O problema é que a maioria dos devs só aprende essas práticas na hora em que o projeto exige. Isso significa aprender sob pressão, muitas vezes depois de um incidente. Praticar hardening em projetos pessoais, mesmo que "de brincadeira", cria o hábito antes que ele seja cobrado a sério.
