DevSecOps na Prática: Construindo uma API Blindada na Nuvem
Por Flaviana Pina | QA Architect & Business Analyst
Durante a construção deste portfólio, tomei uma decisão de arquitetura: eu não queria depender de serviços terceirizados (como o Formspree) para gerenciar o envio de formulários. Como QA e BA, eu queria assumir o controle total (Ownership) da aplicação. Desenvolvi minha própria API em Node.js (Express), mas o caminho até a produção exigiu habilidades avançadas de DevSecOps e Cloud.
1. O Bloqueio da Nuvem (Debugando SMTP Timeout)
Após fazer o deploy da minha API na plataforma Render, os e-mails pararam de chegar. Ao investigar os logs do servidor, encontrei um erro clássico: ETIMEDOUT (Connection Timeout) no módulo Nodemailer.
A Análise: Provedores de nuvem (Render, AWS, Vercel) costumam bloquear o tráfego de saída nas portas SMTP padrão (25, 465, 587) em contas gratuitas para evitar que robôs enviem SPAM. A requisição morria antes mesmo de sair do servidor.
A Solução: Ao invés de brigar com a infraestrutura, mudei a estratégia de rede. Aposentei o Nodemailer e integrei a API do Resend, que realiza o disparo de e-mails via requisições web HTTP (Porta 443). Como o tráfego HTTPS nunca é bloqueado, os e-mails passaram a chegar na velocidade da luz.
2. Identificando Débito Técnico (Technical Debt)
Com a API de contato funcionando, realizei uma análise exploratória no front-end e identifiquei um débito técnico silencioso: o formulário de "Depoimentos", que ficava em um modal, ainda estava utilizando a infraestrutura terceirizada do Formspree. Imediatamente escalei uma refatoração, criando uma rota dedicada /api/testimonial no meu backend e centralizando 100% da arquitetura sob meu controle.
3. Defesa Cibernética: O Honeypot (Pote de Mel)
Expor uma API pública na internet é um convite para robôs de spam. Para blindar a minha caixa de entrada sem prejudicar a experiência do usuário (UX) com CAPTCHAs irritantes, implementei a técnica do Honeypot.
Adicionei um campo invisível no front-end (via CSS). Humanos não o veem, logo não o preenchem. Robôs validam o HTML e preenchem todos os campos. No back-end, inseri uma interceptação cirúrgica:
console.log("🛡️ [DEVSECOPS] Bot de spam detectado e bloqueado!");
// Ghost Banning: Retornamos sucesso (200) para enganar o Bot, mas não enviamos o e-mail.
return res.status(200).json({ sucesso: true });
}
4. Defesa em Profundidade: Sanitização Anti-XSS e Rate Limiting
A segurança não deve depender de apenas uma barreira. Durante nossos testes automatizados no Playwright, simulamos a injeção de um payload malicioso (XSS - Cross-Site Scripting) enviando a tag <script> pelo formulário. Para garantir que nenhum código executável chegasse ao banco de dados ou ao meu e-mail, criei uma camada de sanitização nativa na API:
const sanitizeText = (text) => {
if (!text) return text;
return text.toString().replace(/</g, "<").replace(/>/g, ">");
};
Em conjunto com o OWASP ZAP (que forçou a inclusão de políticas CSP no Front-end), também adicionei a biblioteca express-rate-limit na API, mitigando riscos de Ataques DDoS ao limitar o envio de mensagens para no máximo 3 tentativas a cada 15 minutos por IP.
Conclusão
O papel do profissional de QA evoluiu. Garantir a qualidade de um software moderno exige que saibamos navegar pelos logs do servidor, compreender bloqueios de rede, refatorar débitos técnicos e projetar sistemas seguros "by design" (DevSecOps). Ao tomar as rédeas da arquitetura do meu portfólio, apliquei exatamente essa visão.