Pular para o conteúdo
Samara Alanna.dev

Bajaj

Site institucional da Bajaj, a terceira maior montadora de motos do mundo, com 77 páginas de concessionária e integração com CRM. Entrei para corrigir bugs e acabei reescrevendo a validação de leads, centralizando credenciais e implantando versionamento. Aqui eu conto as três frentes que mudaram a estrutura do projeto.

PAPEL
Desenvolvimento full stack, segurança e infraestrutura
CLIENTE
Bajaj do Brasil, via TecSinapse
PERÍODO
2026
STACK
PHP, JavaScript, jQuery, WordPress, Git, SSH
TIME
Sozinha, com repasse ao time de infra

CONTEXTO

Um site grande, sem versionamento e com credencial em texto puro

WordPress com tema customizado. Páginas de modelo de moto, 77 páginas de concessionária, formulários de interesse e test ride, mapa interativo de concessionárias e integração com CRM corporativo por API e Amazon SES.

Atuo na manutenção do site: incluo novas concessionárias, analiso e corrijo bugs, aplico melhorias de segurança e desenvolvo novas páginas e funcionalidades. O que começou como uma fila de tickets virou nove frentes de trabalho. Seis foram correções pontuais, como o mapa de concessionárias com busca por estado, a proteção contra duplo clique e a limpeza de arquivos órfãos no servidor. As outras três mudaram a estrutura do projeto.

LEADS

Um módulo central para os 106 formulários

O time comercial recebia lead com CPF inválido e sem rastreio de origem. A mesma verificação faltava em quatro lugares ao mesmo tempo: o campo HTML só conferia o tamanho, a máscara formatava sem validar, o servidor confiava no que o front mandava, e o endpoint aceitava envio de bot. Escrevi um módulo PHP central e um JavaScript compartilhado. Como as 77 páginas carregavam o mesmo arquivo, um deploy alcançou os 106 formulários.

ANTES
ANTES
<input name="cpf" pattern=".{11,14}" required>

$("#cpf").mask("000.000.000-00")
if (cpf.length >= 11) enviarLead(form)

// no servidor: nenhuma verificação
DEPOIS - validacao.php
DEPOIS - validacao.php
function cpf_valido(string $cpf): bool {
  $cpf = preg_replace("/\D/", "", $cpf);
  if (strlen($cpf) !== 11) return false;
  if (preg_match("/^(\d)\1{10}$/", $cpf)) return false;
  return digitos_verificadores_ok($cpf);
}

CREDENCIAIS

113 arquivos com a mesma senha escrita dentro

As credenciais SMTP do Amazon SES estavam escritas direto no código, repetidas em 113 arquivos PHP do tema. Criei um arquivo único de configuração e refatorei os 113 para apontar para lá. Trocar a senha passou a ser uma alteração em um arquivo só.

Depois fiz uma auditoria de segurança e entreguei um relatório com os achados por severidade, separando o que eu podia corrigir sozinha do que precisava do time de infraestrutura. Corrigi o que estava na minha alçada e repassei o resto.

VERSIONAMENTO

De nenhum controle de versão a deploy automático

O site não tinha controle de versão. Toda publicação era manual por FTP, sem histórico, e um desenvolvedor podia sobrescrever o trabalho do outro.

Inicializei o repositório no tema e configurei o ignore para deixar de fora credencial, imagem, log e backup. A limpeza do histórico levou o repositório de 2,68 GB para 3,4 MB. Liguei o deploy automático a cada push e escrevi um guia de versionamento para o time.

ANTES

2,68 GB

repositório com histórico sujo

DEPOIS

3,4 MB

depois da limpeza

RESULTADO

Em números

106
formulários com validação dupla
113
arquivos refatorados para credencial única
8
vetores de segurança auditados
83
formulários protegidos contra duplo clique
11
páginas corrigidas com uma linha de CSS
700+
arquivos órfãos removidos do servidor
PRÓXIMO PROJETOVOGE Brasil