O que aprendi sobre segurança implementando hardening em um projeto que não lida com dinheiro

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.

As práticas que apliquei (e que valem para qualquer stack)

Content Security Policy (CSP)

Defini quais origens podem carregar scripts, estilos e conexões dentro da aplicação. Isso reduz o risco de ataques de XSS, já que scripts injetados por terceiros não têm permissão para rodar fora do que foi declarado. No vercel.json do projeto, a política ficou assim.

"Content-Security-Policy",

"value": "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data:; object-src 'none'; frame-ancestors 'none'"

Junto com o CSP, adicionei outros headers de proteção padrão, como X-Frame-Options, X-Content-Type-Options e Referrer-Policy, cobrindo clickjacking e vazamento de informação em requisições cross-origin.

Atualização de dependências e CVEs

O Vite teve uma vulnerabilidade conhecida em uma das versões que eu usava. Corrigir isso não foi opcional. No package.json, a versão fixada hoje é a seguinte.

"devDependencies": {

  "vite": "5.4.20"

}

Essa versão corrige a CVE-2025-58752, relacionada ao servidor de preview do Vite, que podia servir arquivos HTML fora do diretório de build quando exposto à rede. Manter dependências atualizadas é uma das formas mais simples e mais negligenciadas de reduzir superfície de ataque.

Interação mínima, superfície mínima

O Templo Digital não tem formulários nem input de texto. A única interação do usuário é um botão que desce a tela para a próxima seção. Isso não é uma prática de segurança em si, mas é um lembrete útil. Quanto menos pontos de entrada uma aplicação expõe, menor a superfície de ataque desde o início, antes mesmo de pensar em qualquer tratamento de dado.

Documentação das decisões de segurança

Registrei no docs/ do projeto o motivo de cada configuração. Isso ajuda outro dev (ou eu mesmo, meses depois) a entender por que aquela regra existe, em vez de simplesmente removê-la achando que é redundante.

O que isso tem a ver com fintech

Sistemas financeiros levam esses princípios a um nível bem mais rigoroso. Autenticação forte, criptografia de dados em repouso e em trânsito, logs de auditoria, controles de acesso granulares e conformidade com normas como PCI DSS e LGPD.

A boa notícia é que o raciocínio de base é o mesmo que apliquei em um projeto de vitrine 3D. A diferença está na intensidade e no nível de exigência regulatória, não no conceito. Quem já pratica esse tipo de cuidado em projetos pequenos chega mais preparado quando o projeto de verdade envolve dinheiro de alguém.

Próximo passo

Meu plano agora é aprofundar esse tipo de prática do lado do backend, estudando como o ecossistema Spring trata autenticação, criptografia e controle de acesso em aplicações que realmente processam transações. Fica o convite para quem também está migrando de outra área para tech. No fim, o que eu quis testar foi o hábito, não o projeto. Se eu só configurar CSP quando alguém me obrigar, já é tarde.