Este exemplo isolado é invulnerável à injeção.

Mas você tem que perceber que a proteção contra injeção de sql não é apenas uma substituição de caractere . E as circunstâncias podem diferir daquelas que você está considerando no momento. Portanto, seu código se tornaria vulnerável a longo prazo, devido a desvantagens essenciais desse método :

• substituição de caractere é apenas uma parte da formatação necessária
• essa substituição específica pode ser aplicada apenas a strings, deixando outras partes absolutamente desprotegidas.
• essa substituição é externa à execução de uma consulta, o que significa que está sujeita a erros humanos de qualquer tipo.
• essa substituição é uma medida essencialmente destacável, o que significa que pode ser movida para muito longe da execução real da consulta e eventualmente esquecida.
• esse tipo de escape é propenso a ataque de codificação , tornando a solução muito limitada em uso.

Não há nada de errado na substituição de caracteres em si, mas apenas se for usada como parte da formatação completa; aplicado à parte correta da consulta; e feito por um driver de banco de dados, não por um programador; logo antes da execução.

As funções que você propôs nos comentários são um bom passo, mas ainda insuficientes, estando sujeitas às desvantagens listadas acima, tornando-as propensas a todos os tipos de erros humanos.

E a injeção de SQL não é o único problema com essa abordagem, também é uma falha de usabilidade, pois essa função estragaria seus dados, se usada como uma encarnação tardia aspas mágicas , ou tornar seu código inchado, se usado para formatar todas as variáveis ​​diretamente no código do aplicativo.

Essas funções podem ser usadas apenas para processar um espaço reservado , mas é claro que não usando uma função de substituição caseira, mas uma função adequada fornecida pela API do banco de dados.