Nomeie o destino imediato
Suponha que o valor de pesquisa seja A&B "C". Em um componente de consulta de URL, o e comercial (&) normalmente separa parâmetros; por isso, ele deve ser codificado como parte do valor antes de montar a string de consulta. Em um nó de texto HTML, o e comercial pode iniciar uma referência de caractere, e o sinal de menor que (<) pode iniciar uma tag. Dentro de um literal de string JavaScript, aspas e barras invertidas têm significado sintático próprio. Esses três contextos são analisados de maneiras distintas. Um valor seguro em um contexto não é automaticamente seguro em outro. Em produção, use APIs e modelos que respeitem o contexto, em vez de concatenar manualmente HTML ou código.
Trabalhe o primeiro limite
Se a chave de consulta for q, codifique o valor como um componente de URL e coloque-o após q=. O ampersand torna-se %26 e as aspas são representadas de acordo com as regras do codificador de URL. Codificar todo o URL acabado como se fosse um valor também codificaria sua pontuação estrutural e produziria o endereço errado. Se o URL resultante for exibido como texto de link em uma página HTML, o nó de texto precisará de uma representação HTML-safe. Se ele for colocado em um atributo HTML, use um serializador seguro para atributos, que tem suas próprias regras de citação.
- Valor bruto: A&B “C”
- Componente URL: codificar caracteres reservados de consulta
- Saída HTML ou JavaScript: escape para esse destino
Não faça JavaScript o formato de transporte
Um script pode precisar armazenar o valor original em um literal entre aspas, que chama para JavaScript string escaping. Isso é uma preocupação de código fonte, não um substituto para codificação de componentes URL ou codificação de saída HTML. Evite colocar entrada não confiável diretamente dentro da fonte de script inline; usar atributos de dados ou um elemento de script com JSON cuidadosamente serializado pode ser mais seguro quando implementado por estruturas mantidas. A ferramenta de escape MultiVerto JavaScript ilustra caracteres de cadeia de caracteres literais, mas não pode certificar que um aplicativo inteiro é seguro contra injeção de script. A segurança depende do contexto real do analisador e do código circundante.
Decodificação na ordem oposta
No lado de recepção, um analisador de URL extrai q e percent-decodes o componente uma vez. Um analisador HTML processa entidades enquanto constrói seu documento; um navegador não decodifica porcentagem de texto comum apenas porque ele aparece em uma página. JavaScript interpreta seus próprios escapes literais quando analisa o código fonte. Aplicar o decodificador errado pode deixar sequências visíveis como %26 ou criar dados que são interpretados como sintaxe em outro contexto. Mantenha o valor bruto original separado de cada representação serializada para que uma exibição voltada para o usuário não se torne acidentalmente a próxima entrada de processamento.
Uma lista de verificação de revisão para um aplicativo real
Trace o caminho do valor original até o componente da URL, depois até um nó de texto ou atributo HTML e, somente então, até qualquer uso em script. Em cada etapa, escolha uma API adequada ao destino exato. Teste e comercial (&), aspas, sinal de menor que (<) e letras não ASCII. Confira a página renderizada e a URL analisada, não apenas uma string codificada intermediária. O escape não torna um valor confiável nem valida o destino de um link; outras verificações de segurança podem ser necessárias. Os conversores relacionados ajudam a demonstrar cada camada com uma pequena amostra antes de implementá-la em uma aplicação.