Base de Conhecimento

A resposta curta: a injeção de SQL e o XSS são dois dos ataques mais antigos a sites, e continuam a funcionar porque nascem de um mesmo descuido: confiar no que o visitante escreve. Se o seu site é feito com WordPress e plugins mantidos, o risco é de quem os mantém, e o seu trabalho é atualizar. Se é feito por medida, as duas perguntas deste artigo são para quem o programou.

Injeção de SQL

Um formulário de pesquisa mete o que o visitante escreve dentro de uma pergunta à base de dados. Se o programa a monta juntando texto, o visitante pode escrever algo que muda a própria pergunta, por exemplo para ver dados de outros clientes ou apagar tabelas. A defesa é simples e conhecida: consultas preparadas, que mantêm a pergunta e os dados separados. Em PHP, com o PDO:
$st = $pdo->prepare("SELECT * FROM clientes WHERE email = ?");
$st->execute([$email]);
O que nunca se deve fazer é juntar a variável ao texto da consulta.

XSS (cross-site scripting)

Se uma página mostra o que alguém escreveu (um comentário, um nome) sem o proteger, esse alguém pode escrever código que passa a correr no navegador de quem visita a página: roubar uma sessão, mostrar um formulário falso, redirecionar. A defesa é escapar tudo o que se mostra. Em PHP:
echo htmlspecialchars($nome, ENT_QUOTES, 'UTF-8');
No WordPress, as funções esc_html() e esc_attr() fazem o mesmo.

Perguntas para fazer a quem programa

O que a hospedagem faz e não faz

Uma firewall de aplicações web, como o ModSecurity, bloqueia muitos pedidos que parecem estes ataques. É uma rede de segurança, e não uma desculpa para programar mal: veja ModSecurity e firewalls de aplicações web. Os cabeçalhos de segurança também ajudam a limitar o estrago de um XSS: Cabeçalhos de segurança.