DEV Community: Ewerson Benigno

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

Ewerson Benigno — Fri, 10 Jul 2026 12:04:11 +0000

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.

Pipes e Redirecionamento no Linux: o que eu aprendi estudando o terminal no celular

Ewerson Benigno — Fri, 26 Jun 2026 23:37:57 +0000

Eu estava no Termux, um emulador de terminal para Android, rodando uns comandos básicos de estudo, quando digitei algo simples:

ls > arquivos.txt

Não aconteceu nada. O terminal ficou em silêncio.
Meu primeiro instinto foi achar que o comando tinha falhado. Mas quando rodei cat arquivos.txt, o conteúdo estava lá, o ls tinha funcionado, só que a saída não foi para a tela. Foi para dentro do arquivo.
Esse momento me fez querer entender o que estava acontecendo por baixo. Este artigo é o resultado disso.

Os três canais de todo comando Linux

Antes de falar em pipes e redirecionamento, preciso falar sobre como o Linux enxerga a comunicação de um programa.
Todo processo no Linux tem três canais abertos por padrão:

Canal	Número	O que é
stdin	0	Entrada de dados
stdout	1	Saída normal
stderr	2	Saída de erros

Por padrão, stdout e stderr aparecem na tela, e stdin vem do teclado. Mas você pode mudar isso e é aí que a mágica acontece.

Redirecionamento de saída com >

O operador > redireciona o stdout de um comando para um arquivo.

ls > arquivos.txt

O que acontece aqui:
• ls gera a listagem de arquivos (stdout)
• > intercepta essa saída antes de chegar na tela
• O conteúdo vai para dentro de arquivos.txt
• Se o arquivo não existir, ele é criado
• Se já existir, o conteúdo anterior é sobrescrito
Para adicionar ao invés de sobrescrever, use >>:

ls >> arquivos.txt

Redirecionando erros com 2>

O canal de erros é separado do canal de saída. Para capturá-lo, você usa 2>.

cat arquivo_que_nao_existe.txt 2> erro.txt

Tente rodar os dois e compare:

# Isso imprime o erro na tela
cat arquivo_que_nao_existe.txt

# Isso salva o erro em um arquivo (nada aparece na tela)
cat arquivo_que_nao_existe.txt 2> erro.txt

# Confirme que o erro foi salvo
cat erro.txt

Isso é útil quando você roda um script longo e quer guardar os erros para analisar depois, sem poluir a saída normal.

Juntando stdout e stderr no mesmo arquivo

Às vezes você quer capturar tudo, saída e erro, no mesmo lugar:

comando > tudo.txt 2>&1

O 2>&1 significa: "redirecione o canal 2 (stderr) para onde o canal 1 (stdout) estiver indo."
A ordem importa. Isso aqui não funciona como esperado:

# Ordem errada — resultado não é o que você espera
comando 2>&1 > tudo.txt

Nessa ordem, o 2>&1 é avaliado primeiro — quando ainda não há redirecionamento de stdout, então o stderr é vinculado à tela. Depois o > tudo.txt redireciona só o stdout para o arquivo. Resultado: o arquivo recebe apenas o stdout, e o stderr continua aparecendo na tela. O inverso do que você queria.

Pipes com |: compondo

O pipe | conecta a saída de um comando à entrada do próximo. É como criar uma linha de montagem.

ls -l | grep ".txt"

O que acontece:

ls -l lista todos os arquivos com detalhes
| passa essa saída como entrada para o grep
grep ".txt" filtra e mostra só as linhas que contêm .txt Outro exemplo prático, procurar um processo em execução:

ps aux | grep java

Você pode encadear quantos pipes quiser:

cat arquivo.txt | sort | uniq | wc -l

Isso lê um arquivo, ordena as linhas, remove duplicatas e conta quantas restaram, tudo em um único comando.

tee: saída na tela e no arquivo ao mesmo tempo

O > escolhe entre tela ou arquivo. O tee faz os dois:

ls | tee listagem.txt

A saída aparece na tela e é salva no arquivo simultaneamente. Útil quando você quer acompanhar o que está acontecendo em tempo real e ainda guardar o resultado.

Resumo visual

comando             → stdout → tela (padrão)
comando > arquivo   → stdout → arquivo
comando >> arquivo  → stdout → arquivo (acumula)
comando 2> erros    → stderr → arquivo
comando 2>&1        → stderr → mesmo lugar que stdout
cmd1 | cmd2         → stdout do cmd1 → stdin do cmd2
cmd | tee arquivo   → stdout → tela e arquivo

Por que isso importa

Esses conceitos parecem simples, mas são a base de como scripts shell funcionam, como logs são gerados, como pipelines de dados são construídos, e como você compõe ferramentas pequenas para resolver problemas grandes.
No Linux, cada ferramenta faz uma coisa bem feita. Pipes e redirecionamento são o que permite combiná-las.
Comecei a entender isso rodando um ls no Termux às 19h num sábado. Às vezes o aprendizado começa em lugares assim.

Como pensar em UX mesmo sendo desenvolvedor front-end iniciante

Ewerson Benigno — Sat, 30 May 2026 23:58:17 +0000

Quando iniciei minha primeira Landing page não sabia nada sobre UX.
Sabia estruturar um HTML, sabia usar o CSS e eu tinha um objetivo claro: desenvolver uma Landing page para uma amiga maquiadora. Era meu primeiro projeto, tentei "caprichar" ao máximo, foco nos detalhes. Então percebi que estava fazendo mais do que apenas criar um código, analisava o tempo todo sobre como seria a interação dos clientes dela com a página e como isso se converteria em lucro para o seu negócio.
Somente depois de estudar mais a fundo sobre front-end que entendi como esse "olhar aos detalhes" se chamava: UX - User Experience, a Experiência do Usuário.

O que é UX

Na prática, UX é uma pergunta que você faz antes de escrever qualquer linha de código: “Quem vai usar isso e o que essa pessoa precisa encontrar?”
É isso, parece algo básico, mas muda completamente a forma como você constrói o seu projeto. Um desenvolvedor que não pensa em UX olha apenas a estética, ele fica naquilo que é atrativo aos olhos do usuário. Um desenvolvedor que pensa em UX desenvolve pensando na necessidade do cliente.

Decisões de UX que você toma sem perceber
Muitas pessoas não percebem mas já praticam UX sem nem perceber.
Toda vez que você decide onde colocar um botão, um texto, um link ou como quer organizar as seções da sua página, você está tomando uma decisão de UX.
No meu projeto da landing page, tomei várias dessas decisões intuitivamente:
Coloquei o WhatsApp no footer com link direto. O visitante que chega até o final da página já leu tudo e quer entrar em contato, facilitar esse clique é UX.
Posicionei os depoimentos antes do footer. Não foi por acaso, depoimentos constroem confiança. Faz sentido mostrá-los antes de pedir que o visitante entre em contato.
Adicionei um botão de call-to-action no Hero. A primeira seção da página precisa deixar claro o que o visitante deve fazer. Um botão “Saiba mais” ou “Entre em contato” elimina a dúvida.
Todas essas ações têm um princípio em comum, elas pensam no usuário antes de pensar no código.

A diferença entre UI e UX
Antes eu confundia bastante os termos, agora entendo claramente.
UI é o que o usuário vê. É o botão rosa com bordas arredondadas, é a fonte elegante, é a paleta de cores coerente. UI é sobre estética.
UX é o que o usuário sente e faz. É o botão estar no lugar certo, é o texto do botão ser claro o suficiente para o usuário saber o que vai ler ao clicar, é a página carregar rápido o suficiente para ele não desistir. UX é sobre comportamento.
Você pode ter um site com UI perfeita e UX terrível. Um site lindo onde ninguém encontra o que precisa é um site com problema de UX.
O contrário também existe: sites simples visualmente, mas com navegação tão intuitiva que o usuário encontra tudo em segundos. Boa UX, UI modesta.
O ideal, claro, é ter os dois.

Como aplicar UX sem ser especialista
Você não precisa de certificação para começar a pensar em UX. Você pode se fazer algumas perguntas simples na hora de desenvolver:

“Em 3 segundos, o usuário entende o que esse site oferece?”
Se a resposta for não, o Hero da sua página precisa ser refeito. O visitante decide em poucos segundos se vai ficar ou sair.
“Qual é a ação que quero que o usuário tome?”
Entrar em contato, comprar, ou se inscrever, essa ação precisa estar visível, clara e fácil de executar.
“Como isso fica no celular?”
A maioria dos acessos hoje são feitos no mobile. Se você só testa no computador, está ignorando boa parte dos seus usuários.
“Estou facilitando ou complicando?”
Cada clique a mais, cada informação desnecessária, cada campo de formulário que não precisa estar lá, tudo isso é fricção. UX é sobre remover fricção.

Conclusão
Se você está começando no front-end e acha que UX é assunto para depois, é melhor repensar isso.
Você não precisa dominar ferramentas complexas ou ter anos de experiência. Precisa desenvolver o hábito de perguntar: “quem vai usar isso, e o que essa pessoa precisa?”
Essa pergunta, feita com consistência, vai separar o código que você escreve do código que outros escrevem.
E o melhor: você provavelmente já está praticando UX sem perceber. Agora é só dar nome ao que você faz.