Sanitização

Sanitização WordPress é o processo de limpar dados que entram no site (formulários, query strings, headers, payloads de API) removendo caracteres ou estruturas que poderiam ser maliciosos antes de armazenar no banco ou processar internamente. Junto com o escape, que protege a saída de dados, forma a base da defesa contra os ataques mais comuns em WordPress: XSS, SQL Injection e injeção de cabeçalhos. Quem desenvolve plugin ou tema sem sanitizar está abrindo porta para vulnerabilidade.

O que é sanitização

Sanitizar é assumir que todo dado vindo de fora é hostil até prova em contrário. Um campo de texto pode trazer scripts. Um campo numérico pode trazer letras. Um campo de email pode trazer caracteres especiais. Um header HTTP pode trazer quebras de linha forjadas. Sem sanitização, esses dados chegam ao banco como estão, e estouram bug em algum lugar do fluxo.

O processo padrão é receber o input, aplicar uma função de sanitização específica para o tipo de dado esperado, e só então salvar ou processar. Se o usuário envia um nome com tags HTML, sanitize_text_field remove. Se envia um email malformado, sanitize_email retorna string vazia. Se envia uma URL, esc_url_raw normaliza.

Quem busca sanitização wordpress costuma estar tentando entender quando usar cada função, ou descobrindo via auditoria que um plugin antigo aceita inputs sem tratamento. As duas situações pedem o mesmo conhecimento: quais funções existem, o que cada uma faz, e quando aplicar.

O conceito também aparece em contextos não WordPress. Frameworks PHP modernos têm equivalentes próprios. Bibliotecas JavaScript fazem isso no front-end. Em todos os casos a lógica é a mesma: dado vindo de fora é desconfiável até passar por filtro específico.

Funções de sanitização do WordPress

O WordPress oferece um conjunto extenso de funções nativas, cada uma para um tipo de dado. sanitize_text_field é a mais usada: remove tags HTML, codifica entidades, normaliza espaços. Use para qualquer campo de texto livre que não precise aceitar HTML, como nome, assunto, identificador de usuário.

sanitize_email retorna a string só se for email válido, ou vazio se não for. sanitize_key normaliza chaves de array em lowercase com letras, números, underscore e hífen. sanitize_title gera slug a partir de string livre. absint força um inteiro positivo. wp_kses permite tags HTML específicas e descarta o resto.

Para URLs, esc_url_raw é a opção certa antes de salvar no banco. Ela valida o formato, força protocolos válidos (http, https, mailto) e descarta tudo fora do padrão. Não confunda com esc_url, que é função de escape (saída) e não de sanitização (entrada).

Plugins de validação dados wordpress costumam combinar várias funções em pipeline. Um campo de telefone, por exemplo, passa primeiro por sanitize_text_field para remover tags, depois por uma regex específica para forçar o formato, e por fim por uma checagem de comprimento mínimo. Combine com nonce WordPress e capability check para fechar o ciclo de defesa.

Sanitização vs escape

Sanitize wordpress trata dado na entrada. Escape trata dado na saída. Os dois são necessários, e usar só um deles é defesa parcial.

Sanitização limpa o dado antes de salvar. Garante que o que chega ao banco está em formato esperado, sem caracteres que possam quebrar queries ou ser interpretados como código. Funções típicas: sanitize_text_field, sanitize_email, esc_url_raw, absint, wp_kses.

Escape codifica o dado antes de exibir. Garante que o que sai do banco para o navegador, mesmo que tenha algo malicioso por algum motivo, será interpretado como texto e não como código. Funções típicas: esc_html, esc_attr, esc_url, esc_js, esc_textarea. Se você usa esc_html_wordpress no momento de imprimir o conteúdo, mesmo dado contaminado fica neutralizado.

Por que usar os dois? Porque o ataque pode entrar por caminhos que você não controla. Um plugin de terceiros salvou dado sem sanitizar há 3 anos. Você lê esse dado e exibe. Sem escape, o ataque sobrevive. Com escape, é neutralizado independentemente do que tenha entrado no banco. Combinado com proteção contra XSS e SQL Injection nas camadas certas, fecha praticamente todos os vetores comuns.

Boas práticas de segurança

A primeira regra é sanitizar tudo que vem de fora, sem exceção. $_POST, $_GET, $_REQUEST, $_COOKIE, headers HTTP, body de requisições REST, JSON deserializado. Não confie em validação de front-end: ela existe para UX, não para segurança. Toda validação real precisa estar no backend.

A segunda regra é escolher a função certa para o tipo certo. sanitize_text_field para texto plano, sanitize_textarea_field para textareas (preserva quebras de linha), wp_kses para HTML restrito, esc_url_raw para URLs. Usar sanitize_text_field em uma textarea destrói as quebras de linha. Usar wp_kses sem allowlist deixa passar tags perigosas.

A terceira regra é sempre escapar na saída, mesmo dado que você acredita estar limpo. Vulnerabilidade WordPress reais já apareceram em plugins onde a entrada era sanitizada perfeitamente, mas a saída esquecia esc_html em algum ponto. Sanitização é defesa em profundidade, não silver bullet.

Por fim, valide sempre que possível. Sanitização limpa, validação rejeita. Se um campo deveria conter um valor de uma lista fechada (status, role, tipo de pagamento), confira se o valor está na lista antes de prosseguir. Combine com checagens de capability via current_user_can para garantir que o usuário tem permissão para a operação. Para vulnerabilidade WordPress conhecidas, mantenha plugins atualizados.

Para times que precisam levantar a régua de segurança em sites WordPress sem auditar plugin por plugin, a FULL Services entrega o AIOS (All-In-One Security) já licenciado e configurado dentro da stack profissional, com firewall de aplicação, proteção contra payloads conhecidos e hardening que cobre o que sanitização sozinha não resolve. O site roda em uma camada validada em produção desde o primeiro deploy.