La mayoría de errores de URL encoding no parecen dramáticos al principio. Un espacio se convierte en +, un ampersand corta un parámetro, una barra dentro de un ID crea otra ruta, o un valor se decodifica dos veces. El resultado puede ser una búsqueda incorrecta, una firma inválida, un redirect abierto o un recurso distinto al esperado. El problema central es que una URL usa caracteres tanto para datos como para sintaxis.

Path y query no comparten exactamente las mismas reglas

Un valor que se coloca en la ruta debe escapar caracteres que allí tienen significado, especialmente /. En query, & y = separan parámetros. En formularios, el espacio puede aparecer como +, pero en otros componentes + puede ser un carácter literal. Usar una sola función para todo produce errores sutiles.

Las bibliotecas suelen ofrecer APIs distintas para path segments y query parameters. Esa separación no es burocracia: refleja que cada componente tiene una gramática diferente. Construir la URL por componentes evita escapes incorrectos.

El doble encoding crea valores que nadie esperaba

Si %20 se vuelve a codificar, aparece %2520. El receptor que decodifica una vez obtiene el texto %20, no un espacio. Si decodifica dos veces, puede interpretar datos como sintaxis. Esta diferencia rompe firmas, rutas y comparaciones.

La aplicación debe saber si un valor está crudo o ya codificado. Lo más seguro es conservar datos sin codificar internamente y codificarlos solo al construir la URL final. Guardar versiones parcialmente encoded crea ambigüedad permanente.

Concatenar query strings es una trampa común

Un filtro como “R&D” contiene ampersand. Si se concatena ?department=R&D, el servidor puede interpretarlo como dos parámetros. Lo mismo ocurre con valores que contienen =, espacios o caracteres Unicode. La URL parece normal hasta que un caso real contiene sintaxis reservada.

Usar una API de parámetros resuelve el escape y también ayuda con arrays, valores vacíos y repetición de claves. Además deja más claro qué parte de la URL es estructura y qué parte es dato.

Firmas y canonicalization son sensibles a bytes

APIs firmadas suelen calcular HMAC sobre una representación canónica de método, path, query y body. Cambiar el orden de parámetros, la capitalización del percent-encoding o el tratamiento de espacios puede invalidar la firma. El payload lógico puede ser igual, pero los bytes firmados no lo son.

El protocolo debe definir exactamente cómo ordenar, escapar y unir componentes. Productores y consumidores necesitan tests con vectors compartidos. “Funciona en mi cliente HTTP” no basta para un mecanismo firmado.

Decodificar antes de autorizar puede ser peligroso

Routing, proxies y servidores pueden decodificar URLs en distintos momentos. Una secuencia como una barra encoded puede tratarse como dato en una capa y como separador en otra. Si la autorización se aplica a una forma y el acceso a otra, aparece una brecha.

La solución es tener una política clara sobre la forma normalizada que se autoriza y se ejecuta. Las capas deben concordar en si aceptan o rechazan encodings ambiguos, path traversal y segmentos equivalentes.

Unicode añade otra dimensión

Caracteres no ASCII deben convertirse a bytes, normalmente UTF-8, antes de percent-encoding. Si productor y consumidor no coinciden en encoding, el texto recuperado será distinto. Además, algunos caracteres visualmente parecidos tienen code points diferentes, lo que afecta comparación y allowlists.

Los nombres de dominio internacionalizados siguen reglas especiales de IDNA y punycode. Validar hosts con simple comparación visual es insuficiente. Para seguridad, parsea y normaliza con bibliotecas mantenidas.

Los redirects amplifican errores

Un endpoint que recibe next o returnUrl debe validar destino, no solo codificación. Un valor perfectamente encoded puede apuntar a un dominio externo o usar un esquema peligroso. También puede esconderse mediante doble encoding si la aplicación decodifica en etapas.

Una buena política permite rutas internas relativas o una lista cerrada de hosts. Después de validar significado, se aplica encoding para construir la respuesta. Escapar no reemplaza la decisión de navegación permitida.

Los logs pueden mentir por legibilidad

Algunas herramientas muestran URLs decodificadas para que sean fáciles de leer. Otras registran la forma cruda. Durante debugging, comparar logs de distintas capas puede confundir si no se sabe qué representación muestra cada una. Un valor parece cambiar solo porque una herramienta lo presentó distinto.

Para incidentes complejos, guarda request target crudo, forma parseada y resultado normalizado cuando sea seguro. Esa visibilidad ayuda a encontrar la capa que alteró el significado.

La prevención está en construir, no reparar

Los errores de URL encoding disminuyen cuando el código trabaja con objetos URL, path segments y query parameters, no con strings concatenados. También ayudan límites de entrada, tests con caracteres reservados, reglas de canonicalization y validación por componente.

Una URL correcta no es solo una cadena que “se ve bien”. Es una estructura donde cada carácter reservado mantiene su papel. Respetar esa estructura evita bugs que solo aparecen con nombres reales, idiomas reales y enlaces compartidos por usuarios reales.