Sim, eu entendo. Mas existem algumas coisas que são realmente desnecessárias. Se fosse um script com acesso ao banco de dados, por exemplo, e você quisesse realmente não deixar nenhuma brecha, então seria interessante utilizar expressões regulares, addslashes E mysql_real_escape_string. Sim, podem haver formas de burlar o addslashes tal como já houve (mas já foi consertado). Dessa forma, um script definitivamente seguro para envio de email, por exemplo, ficaria assim:

if(preg_match(‘/[\w+.-_]{2,20}@[\w]{2,20}\.[\w]{2,4}/’, $_POST['blabla']))
{
$variavel_recebida = mysql_real_escape_string(addslashes($_POST['blabla']));
}

Esse é definitivamente um tratamento de variáveis seguro. O exemplo acima é o que eu utilizo em meus sistemas. Claro que, às vezes, dá para brincar um pouco adicionando um:

if(preg_match(‘/[\w+.-_]{2,20}@[\w]{2,20}\.[\w]{2,4}/’, $_POST['blabla']))
{
executa
}
elseif(preg_match(‘/[\'\"]+/’, $_POST['blabla']))
{
echo “Bela tentativa, campeão =/”;
}

Esse é definitivamente um tratamento de variáveis seguro. O exemplo acima é o que eu utilizo em meus sistemas. Claro que, às vezes, dá para brincar um pouco adicionando um:

Se o script não chega nem perto de um banco de dados, porque raios se preocupar com magic quotes? Se fosse, ao invés de mandar um email, escrever os dados dentro do servidor, só deveria se preocupar com outras linguagens que pudessem ser escritas no corpo da mensagem como , por exemplo. Isso poderia ser feito filtrando os dados com expressões regulares, tipo: if(preg_match(‘/^[a-zA-ZÀ-ú[:PUNCT:] ]+$/’, $_POST['blabla'])) ou ‘/^[\a]+/’.