Validación de entradas y codificación de salidas

Las vulnerabilidades de inyección — SQL, comandos, LDAP, XPath y otras — surgen cuando una entrada no confiable se interpreta como código. La validación de entradas garantiza que los datos cumplan los tipos, longitudes y formatos esperados antes de procesarlos, almacenarlos o devolverlos.

La validación mediante una lista de permitidos (allowlist) define lo que SÍ es aceptable: solo caracteres alfanuméricos, solo enteros del 1 al 100 o solo formatos de correo electrónico válidos. Una lista de bloqueados (denylist) intenta bloquear entradas maliciosas conocidas y siempre queda incompleta. Prefiera las listas de permitidos.

La validación del lado del cliente mejora la experiencia de usuario, pero no aporta ninguna seguridad: los atacantes la omiten fácilmente mediante las herramientas de desarrollo del navegador o curl. Valide siempre en el lado del servidor. La validación del lado del cliente es una cortesía; la del lado del servidor es el control de seguridad.

Números: compruebe el tipo y el rango. Cadenas: compruebe la longitud y el conjunto de caracteres. Fechas: analícelas estrictamente y compruebe el rango. Archivos: compruebe la extensión Y los magic bytes/el tipo MIME; nunca confíe únicamente en la extensión. URL: analice y valide los componentes del esquema, el host y la ruta.

La medida más importante al validar entradas para bases de datos es no concatenar nunca la entrada del usuario en SQL. Utilice consultas parametrizadas (prepared statements), donde la entrada del usuario se pasa como parámetro y no se interpola en la cadena de consulta.

La misma cadena requiere una codificación diferente según el contexto. Cuerpo HTML: codificación HTML (< > &). Atributo HTML: codificación de atributos HTML. JavaScript: escape de JS. Parámetro de URL: codificación de URL (codificación porcentual). Utilizar una codificación incorrecta deja brechas que los atacantes pueden explotar.

No inserte nunca directamente en HTML los datos del usuario. Utilice un motor de plantillas o una biblioteca que aplique automáticamente el escape de HTML. En React, {value} es seguro; dangerouslySetInnerHTML omite el escape. En Django, las plantillas aplican el escape automáticamente, a menos que utilice explícitamente el filtro safe.

Al insertar datos en JavaScript (por ejemplo, una variable inicializada con datos del usuario), la codificación HTML no es suficiente. Utilice la codificación JSON: JSON.stringify(value). Esto evita que los datos salgan del contexto de un literal de cadena de JS.

Los datos proporcionados por el usuario que se insertan en URL deben codificarse porcentualmente mediante encodeURIComponent() (JS) o urllib.parse.quote() (Python). Los datos sin codificar pueden manipular la estructura de la URL, lo que puede provocar redirecciones abiertas o recorrido de rutas.

CSP añade una segunda línea de defensa contra XSS. Una CSP estricta que utiliza nonces impide la ejecución de scripts insertados incluso si se inyecta una carga útil de XSS, porque el navegador se niega a ejecutar scripts sin el atributo nonce correcto.

El XSS basado en DOM ocurre cuando JavaScript lee de fuentes controladas por el atacante (location.hash, document.URL, cookie) y escribe en sinks peligrosos (innerHTML, document.write, eval). Audite todos los flujos de datos desde las API del navegador hasta los sinks del DOM mediante herramientas de análisis estático.

¿Por qué es esencial validar las entradas en el lado del servidor incluso cuando se ha implementado la validación del lado del cliente?

La validación de entradas (listas de permitidos, comprobación de tipos y límites de longitud), combinada con la codificación de salida sensible al contexto (HTML, JS, URL y parametrización SQL), constituye la defensa principal contra los ataques de inyección y XSS. Ambas deben aplicarse en el lado del servidor sin excepción.