Quando assumo manutenção de um sistema PHP legado, reviso mentalmente contra o OWASP Top 10 antes de qualquer outra coisa. Não porque toda vulnerabilidade lá vá aparecer, mas porque a maioria dos problemas graves que já encontrei em produção estava exatamente nessa lista.
Os que mais encontro na prática
Falhas de controle de acesso — endpoints que checam autenticação mas não autorização, deixando um usuário comum acessar dado de outro — e injeção (SQL, mas também de comando de sistema em uploads mal validados) são disparados os mais comuns em código legado. Configuração de segurança mal feita vem logo atrás: senha de banco em repositório público, `.env` versionado por engano, painel administrativo sem autenticação nenhuma.
Por que legado é mais vulnerável que código novo
Não é que quem escreveu o código legado fosse descuidado — é que boas práticas de segurança evoluíram, e código de anos atrás carrega decisões que faziam sentido na época e não fazem mais. A mesma disciplina que uso pra tratar autenticação e permissões de forma centralizada ajuda a evitar boa parte dessas falhas de controle de acesso antes mesmo delas existirem.
Segurança é processo, não checklist único
Reviso contra OWASP uma vez na auditoria inicial, mas a proteção real vem de manter esse cuidado em toda mudança nova — o próximo post desta série detalha um risco específico que continua extremamente comum: SQL Injection.
