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.
Top comments (5)
O
'unsafe-inline'no seuscript-srcdesliga na prática a maior parte da proteção XSS que o CSP deveria dar — com ele qualquer script inline injetado executa normalmente, que é exatamente o vetor que você quer bloquear. Para um projeto de treino isso é o detalhe que vale a pena resolver de verdade, porque no dia em que for fintech você vai encontrar a mesma parede: Three.js e várias libs de bundler costumam empurrar você praunsafe-inlinee a saída correta é nonce ou hash por script, não afrouxar a política toda.E é aqui que o hábito importa mais do que o header: um CSP com
unsafe-inlinepassa em quase todo scanner automático e ainda aparece verdinho no relatório. O aprendizado que se transfere pra sistema com dinheiro não é "configurei CSP", é "aprendi a ler o CSP e enxergar que ele não estava fazendo o que eu achava". Fixar a versão do Vite pra fechar a CVE-2025-58752 foi a parte fácil e concreta — a difícil é essa, calibrar a diretiva pra não te dar uma falsa sensação de segurança.Boa observação. Configurei o CSP achando que já tava protegido, mas o unsafe-inline deixa a proteção só na aparência, passa em qualquer scanner, mas não bloqueia o vetor que importa de verdade. Vou trocar pra nonce por script. Valeu por apontar, ajudou bastante no meu aprendizado.
The most useful security habit here is not treating hardening as something reserved for payment systems. Any app that stores identity, user behavior, or trust signals has something worth protecting. The mindset shift is from "does this handle money" to "what damage could a quiet failure cause."
That's exactly the point I wanted to get across. "Does it handle money?" is a limited criterion, the right question is what damage a silent failure could cause, whether to identity, behavior, or any trust signal. Thanks for the summary, you captured the core idea well.
You framed it well in the post. Money is only one visible proxy for risk. Trust, identity, access, and silent behavior changes can be just as damaging, especially because teams underestimate them until the failure is already public.