SQL Injection é ensinado em qualquer curso introdutório de segurança, e mesmo assim continua aparecendo em código de produção — inclusive em projetos que eu já auditei. A técnica de ataque é bem documentada há mais de duas décadas; o problema nunca foi falta de informação, foi disciplina de aplicação.
Onde ele ainda aparece
Raramente vejo SQL Injection em queries construídas com Eloquent ou Query Builder do Laravel — o framework já protege por padrão. O risco reaparece quando alguém escreve uma query raw concatenando valor de input diretamente na string, geralmente sob pressão de prazo, "só dessa vez". Uma única exceção a essa regra é o suficiente para expor todo o banco de dados.
A disciplina que aplico
Uso prepared statements e binding de parâmetro como regra absoluta, sem exceção "só essa vez uma vez". Quando preciso de uma query mais complexa que foge do Query Builder padrão, ainda assim uso os métodos do próprio Laravel que aceitam bindings — nunca concateno valor de usuário direto na string SQL, independente de quão "controlado" pareça o input naquele momento.
O próximo risco na fila
Depois de proteger contra injeção de dado, o próximo ponto que reviso é como a aplicação decide quem pode fazer o quê — tema que aprofundo em JWT vs sessão, sobre as duas formas mais comuns de autenticação que já implementei.
